agl

This is mostly complaining about a lack of FIPS 140 compliance. While that might be a regulatory issue for a .gov site, technically-speaking FIPS compliance is a hinderance to building a sound system, not an aid.

Putting that aside, there might be some valid points in here: using Hash(IKM + nonce) to generate a key is probably not ideal, depending on what Hash is. That's generally a job for HKDF. The post also mentions a "non-approved KDF" elsewhere, but doesn't say what it is.

On the other hand, storing Hash(key) isn't immediately an issue unless something else in the scheme depends on Hash(key) being secret, but the post implies without justification that it's some sort of obvious error.

So there might well be some issues here, but this post doesn't provide sufficient detail to condemn login.gov out of hand.

Unfortunately, one of the important citations ([5], "Proof of Replication") does not appear to be available. (Or, at least, Google cannot find it.)

It turned out that breaking the combination is SHA-1 and MD-5 is much easier than people expected: https://www.iacr.org/archive/crypto2004/31520306/multicollis...

If I may (hopefully accurately) summarise your argument: the sponge construction means that we could just implement a single permutation in hardware / optimised software and build everything from it, thus saving die area / code size, and complexity.

But deciding to skip SHA-3 doesn't preclude any of that. SHA-3 is the hash standard itself, and even the Keccak team appear to be pushing K12 rather than SHA-3. It seems unlikely that a full set of primitives built around the Keccak permutation would choose to use the SHA-3 parameters at this point.

Indeed, SHA-3 adoption might inhibit that ecosystem by pushing towards those bad parameters. (I think there's wide agreement that SHA-3 is too conservative.)

On the other hand, you might want SHA-3 because you believe that it'll result in hardware implementations of the permutation and you hope that they'll be flexible enough to support what you /really/ want to do with it. I'm not sure that would be the best approach even if your goal was to move to a permutation-based world. Instead I would nail down the whole family as you would like to see them and use small chips to try and push it. K12 is probably a step in the right direction.

I can confirm that the code size of BoringSSL is something that we worry about for mobile apps. A 50KB increase (which wouldn't be much for an optimised SHA-3) would raise questions.

I admit that when I see the 100MB+ size of apps that I have to download, I do wonder why. But I assume that it would be even worse were people not worrying about this stuff.

By selecting primitives designed for hardware (AES and GHASH) rather than primitives that use operations that are commonly applicable (ChaCha20 and Poly1305), we've ended up with extra hardware to support AES and GHASH. But it's not clear that was actually a good idea, or just path dependence.

ChaCha20, Poly1305, BLAKE2 benefit from improvements that benefit a wide-range of applications, while SHA-3, AES and GHASH do not. Thus the "cost" of high performance support for the former can be amortised over a much wider base.

Gah, thank you. I did, indeed, mean to link to bench.cr.yp.to. Fixed.

(The BLAKE2 page (https://blake2.net/) has a graph too.)

You are correct that renegotiation has been a very rich source of bugs over the years. It has been removed in TLS 1.3.

You would have to ask people who were involved in the early days of SSL to be sure but my impression was that the motivation was centered around the idea that symmetric keys should not be used to encrypt too much information. Thus extra handshakes were thought to be needed in order to "refresh" keys.

That's not inaccurate, although I feel that people wanted to rotate keys out of a sense of unease, rather than based on an analysis of how the security bounds change as the amount of data increases.

Server-gated crypto was certainly a reason, as detailed in a comment here by geofft.

These days (and I don't know if this was in mind when renegotiation was designed), renegotiation in HTTPS is almost exclusively used by servers (often IIS) to request a client-certificate after receiving an HTTP request.

There are much simpler ways to achieve these goals and they have been implemented in TLS 1.3 to replace renegotiation. I think that people were much more confident in their ability to write correct software in the 1990s.

I think you have session resumption in mind. Renegotiation is different and involves performing more than one handshake per connection.

Google has had an intermediate CA for many years (GIAG2) so, if you don't trust Google, this doesn't make things any worse for you.

No plans for a CECPQ2 at the moment, although I believe that the general structure of running both an EC and PQ key agreement concurrently is likely a good idea in the future until time gives us better confidence in the PQ half.

I'm hoping that we'll have some consensus in a year or two on a good candidate PQ algorithm that we can get deployed across several implementations. It might be very similar to NewHope, or perhaps Shor et al will break lattices in general :)

(C in CECPQ1 was "combined".)

https://www.imperialviolet.org/2015/12/24/rlwe.html might be helpful.

This is a good point and we might need to change things because of this; it depends on what client needs turn out to be.

But I'm hoping that the software-update mechanism is the foundation of any modern system, and that can use nonces to show freshness. It's fairly common for systems to update immediately on power-on and hopefully that will get the fresh Roughtime server-list that allows the rest of the system to come up.

(The alternative is that we try to guarantee that Roughtime servers will never change, and that's very hard.)

(Ben was involved in the design of Roughtime.)

We haven't written a spec because we don't intend for this to be widespread. However, the spec would basically be: run both X25519 and NewHope concurrently, concatenate their outputs and feed that into the TLS KDF as normal.

It is indeed a combination of R-LWE and ECC because it doesn't yet seem reasonable to depend on R-LWE alone. Not only because of the possibility of implementation faults in NewHope, but also because of the possibility of significant crypto-analytic advances against R-LWE, even with classical computers.

Yep, that's it. Different platforms need slightly different assembly and, although I wouldn't choose Perl for it, it's not fundamentally that different from any other text-to-text transform.

Handwritten asm still outperforms compiler output by enough to warrant its use in hot functions like AES-GCM.

(NaCl also uses a text-to-text transform system to output asm, although it's written in C and does register allocation too. The important aspect of NaCl is djb & friend's attention to quality.)

I was talking about the addressing at the assembly level, because that's what LEA and addressing modes deal with. However, your references to a spec make a very good point. Maybe I misunderstood Chandler in the first place.

I've pulled the post (since it may be incorrect) until I can sort it out with a compiler person.

Looks like Safari is no longer rendering the fonts correctly. (It used to work but I hesitate to blame Safari because font files are complex and maybe there's a problem with the ones that I'm using.) I've dropped the custom font now.

Overflow can happen and we test for it wherever possible (at least that's the hope). By using unsigned lengths, the overflow tests are simple: x + y < x. We also don't have to worry about negative values which, in my experience, are at risk of being forgotten more often than excessively large ones.

BoringSSL started prior to LibreSSL.

That's correct. OCSP stapling is still in the TLS layer and it returns the OCSP information as an opaque blob.

VU#804060 is talking about "cookie forcing". This is not a new discovery. Here's Chris Evans (not the actor) talking about it in 2008: http://scarybeastsecurity.blogspot.com/2008/11/cookie-forcin...

The best solution is to preload HSTS on a domain and include all subdomains, and we've been saying that for years. That prevents any HTTP connections, although it's obviously not an easy solution in many cases.

The USENIX paper does suggest some unilateral changes to cookie semantics to address this issue, but any such changes have eye-watering compatibility concerns and could only be deployed after a lot of testing.

Chrome has already disabled SSLv3 (as have other browsers). We have also announced the planned removal of RC4 early next year: https://groups.google.com/a/chromium.org/forum/#!msg/securit.... (As have Mozilla and Microsoft.)

I manage SSL operations at Google and, as far I can tell, this is all nonsense.

It's too long to deal with point-by-point, but I can do a few:

* It's not odd that a cert for * .google.com would be served for google.fr. Check the SANs.

* Google does not use EV certificates.

* Google's frontends have many IP addresses. Seeing differences at different times and places is normal.

* Our leaf certificates really are issued for only a few months.

* We will be off SHA-1 by the end of the year but, at the time the article was written, one certainly could have received a SHA-1 signed certificate from us.

* http://clients1.google.com/ocsp is our OCSP responder and, yes, you'll get 404 unless you send a correct OCSP request with a Host header.

The claim about HTTPS not being sufficient for downloading Chrome (or anything else) is incorrect. The page cites https://cryptostorm.org/viewtopic.php?f=67&t=8713 for this, but that's a long page of nonsense.

Most likely what's happening is that HTTP resource loads are being manipulated; thus it appears to affect all browsers. Also possible is that the end-machine has been compromised some other way and the malware is attacking local programs.

As far as a user is concerned, the difference is irrelevant, but we'll never get a grip on problems if even technical pages are fear mongering.

Here is the spec for the winner: https://password-hashing.net/submissions/specs/Argon-v2.pdf

This is a bunch of nonsense. ekr was, for many years, the chair of the TLS working group at the IETF. He worked on TLS for years, which is why you'll see his name on the RFCs for TLS 1.1[1] and 1.2[2]. He's currently doing the bulk of the work on TLS 1.3.

The only hint of an insinuation that he's ever acted against the common interest comes from the fact that his name is also on the Extended Random draft. That's because the supposedly good half of the NSA (the Information Assurance Directorate) asked for that change and needed someone to guide the process through the IETF. Since ekr was so central to the working group and so practiced at it, he ended up writing it as a draft and thus his name got attached.

I bet he seriously regrets that now but, at the time, there was no hint that this was bad. Sure, it was odd, but it was totally plausible that some government process had decreed that some minimum amount of entropy must be included or something so, whatever. Nobody planned to implement it and nobody really cared.

In hindsight, that was naïve—on the part of everyone. But casting aspersions on ekr because of it is just codswallop.

[1] https://www.ietf.org/rfc/rfc4346.txt [2] https://www.ietf.org/rfc/rfc5246.txt

> The tone of the article suggests the author is ready to disregard the templated responses from Save Domain Privacy and others.

I didn't intend to suggest that they be disregard, I just didn't have much to say about them other than their number.

Without these efforts to promote opposition, /I/ wouldn't have heard about this proposal I believe. I certainly don't think that the template messages should be ignored just because of their form.

Chrome will be increasing it's minimum DH group size to 1024 bits: https://groups.google.com/a/chromium.org/forum/#!topic/secur...

But, if you need to spend the time updating a server configuration, just switch to ECDHE instead.

With both AES-GCM and ChaCha20-Poly1305, confidentiality is provided by XORing the plaintext with a keystream generated by either AES or ChaCha20. If the nonce is the same, then the same keystream is used.

Consider two plaintexts, p₁ and p₂, encrypted with the same (key, nonce) pair. The ciphertexts will, in part, contain p₁⊕k and p₂⊕k, where k is the keystream and ⊕ is XOR.

An attacker can XOR those ciphertexts together and get p₁⊕k⊕p₂⊕k = p₁⊕p₂⊕k⊕k = p₁⊕p₂. If the attacker has any knowledge of p₁ or p₂ then the confidentiality of the other falls as well.

The failure of the authenticator is more complex. Both AES-GCM and ChaCha20-Poly1305 use polynomial authenticators and, in short, duplicating a (key, nonce) pair allows the attacker to solve an equation and that's very bad.