agl

11 ms·

31.
by agl 9y ago
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 m
32.
by agl 9y ago
Unfortunately, one of the important citations ([5], "Proof of Replication") does not appear to be available. (Or, at least, Google cannot find it.)
33.
by agl 9y ago
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...
34.
by agl 9y ago
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 si
35.
by agl 9y ago
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
36.
by agl 9y ago
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 n
37.
by agl 9y ago
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.)
38.
by agl 10y ago
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 motivat
39.
by agl 10y ago
I think you have session resumption in mind. Renegotiation is different and involves performing more than one handshake per connection.
40.
by agl 10y ago
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.
41.
by agl 10y ago
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 ho
42.
by agl 10y ago
https://www.imperialviolet.org/2015/12/24/rlwe.html might be helpful.
43.
by agl 10y ago
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
44.
by agl 10y ago
(Ben was involved in the design of Roughtime.)
45.
by agl 10y ago
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
46.
by agl 10y ago
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
47.
by agl 10y ago
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 p
48.
by agl 10y ago
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 f
49.
by agl 11y ago
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
50.
by agl 11y ago
BoringSSL started prior to LibreSSL.
51.
by agl 11y ago
That's correct. OCSP stapling is still in the TLS layer and it returns the OCSP information as an opaque blob.
52.
by agl 11y ago
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...
53.
by agl 11y ago
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 Mo
54.
by agl 11y ago
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 S
55.
by agl 11y ago
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
56.
by agl 11y ago
Here is the spec for the winner: https://password-hashing.net/submissions/specs/Argon-v2.pdf
57.
by agl 11y ago
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 bul
58.
by agl 11y ago
> 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
59.
by agl 11y ago
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,
60.
by agl 11y ago
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₂

More ›