agl

13 ms·

61.
by agl 11y ago
Opps, fixed. Thanks. It should have linked to https://www.imperialviolet.org/2014/06/20/boringssl.html
62.
by agl 11y ago
Any authentication tag is a detail of the AEAD. As a practical matter, in order to provide authentication, the AEAD must expand the plaintext and, in some AEADs, that expansion comes in the form of a tag. But some AEADs just pad the plainte
63.
by agl 12y ago
Done in Chrome with CRLSet 2140.
64.
by agl 12y ago
CRLSet 2140 contains a public-key block for this. If you're on desktop Chrome you can go to chrome://components and check for a CRLSet update manually. If you're testing it, note that Chrome caches certificate validity r
65.
by agl 12y ago
I'm looking into a CRLSet push to block this certificate in Chrome now.
66.
by agl 12y ago
ECC public keys use a different encoding (X9.62). There's nothing in the report that suggests a problem there.
67.
by agl 12y ago
This reported issue is with private key serialisation, not with public keys. So any issues would be at server startup time, when loading keys, rather than with connecting clients.
68.
by agl 12y ago
Nothing much to see here. ECC private keys are just random numbers. The reported issue is that, if the random number happens to be encodable in fewer bytes than expected, the spec says that it should be padded with leading zeros, but OpenSS
69.
by agl 12y ago
At the moment, yes, no nosslsearch VIP will do this. However we're getting rid of it soon and replacing it with one that enables SafeSearch, but still over HTTPS: https://support.google.com/websearch/answer/18
70.
by agl 12y ago
> Your argument would be far more persuasive if Google were really biting the bullet and dropping support for SHA1 even when an old browser connects. That's certainly the plan. What did I say that suggests otherwise?
71.
by agl 12y ago
(Google's certificates only last three months and that's not because of this announcement.) The transition that I'm talking about is the transition to SHA-256 overall. If you're in a position where your CA sold you a cer
72.
by agl 12y ago
Unfortunately we don't have the technical ability, nor do people have the mental capacity, to cope with multiple URL schemes for different "levels" of security. SHA-1 limits the security for everyone and all uses. And if site
73.
by agl 12y ago
This was already announced by Microsoft last year: https://technet.microsoft.com/en-us/library/security/2880823... Unfortunately, many CAs decided to ignore it, presumably on the assumption that Microsoft wou
74.
by agl 12y ago
The world will be switching to SHA-256 - Microsoft already decided that last November [1]. This is just Chrome helping out. Obviously, XP is a problem. We're planning on prompting Chrome users on affected versions to update, both at st
75.
by agl 12y ago
Just to clarify: the other replies are correct. The logic is that if the leaf certificate has an expiry after Dec 31st, 2015 then the whole chain must be SHA-256. If the leaf expires before that, then other certificates in the chain don&#x2
76.
by agl 12y ago
But dumping everything through zlib turned out to be a security hole: http://en.wikipedia.org/wiki/CRIME . I wrote some terrible, terrible code for Chromium to patch zlib in order to segment different sources of data an
77.
by agl 12y ago
> Every time you visit a page the OS/browser doesn't go up the entire chain of trust and check for constraints. Oh, certainly they do. Name constraints work just like that: https://tools.ietf.org/html/rfc52
78.
by agl 12y ago
A Chrome update was needed because the constraint was applied retrospectively. A name constraint is usually an X.509 extension that is included in the certificate.
79.
by agl 12y ago
Name constraints apply all the way down the chain - intermediates are implicitly limited by the constraints on their root. CAs have been name constrained in the past, see the update here about ANSSI: http://googleonlinesecurity.b
80.
by agl 12y ago
http://www.certificate-transparency.org/how-ct-works
81.
by agl 12y ago
torproject.org has public-key pinning in Chrome, although without the "More" information I can't tell whether it's a pinning error or just that your ISP is blocking the site. You can try running: $ openssl s_client -conn
82.
by agl 12y ago
I think the costs and benefits are pretty much what you would expect. If your diff from upstream is small, then the tradeoff strongly favours rebasing against upstream and tracking it. However, as the diff becomes larger, the tradeoff shift
83.
by agl 12y ago
Thanks for that. I've updated the post to mention multi-target attacks and the quantum attack against McEliece (which I wasn't aware of, and is saddening because it appears to make McEliece a much less attractive PQ system). I pic
84.
by agl 12y ago
Previously discussed: https://news.ycombinator.com/item?id=7682537 My comment from last time: Good to note that this was found with KLEE[1]. KLEE is a good for symbolic execution of code and is very cool[2]. This only trigg
85.
by agl 12y ago
Assuming that SHA-256 is sound, then the effort needed to find a collision is 2^128. However efficient your hardware is, multiplying the energy-per-hash by 2^128 results in an impossible number. Let's say that you have a magic device t
86.
by agl 12y ago
I don't think the load balancing is setup as tightly as www.google.com. It doesn't get much traffic after all.
87.
by agl 12y ago
Collision resistance is harder to meet in the same way that "stronger" results are harder to prove. That is, I think you're correct and that my wording was just confusing, sorry! Historically, many hash functions have been br
88.
by agl 12y ago
Good to note that this was found with KLEE[1]. KLEE is a good for symbolic execution of code and is very cool[2]. This only triggers a crash if you use RELEASE_BUFFERS (not the default) and a warning alert is written when the socket buffer
89.
by agl 12y ago
The primary aim[1] of CRLSets was always to be a mechanism via which we could quickly react to CA situations like DigiNotar, ANSSI etc. Doing full binary pushes like we did during a few years back was too heavy. As a secondary aim, we tried
90.
by agl 12y ago
I'd likely say that the records are AEAD ciphertext and let the AEAD decide on what that means. But as for allowing handshake messages, alert messages etc to mix with application data, no. (See the QUIC design as an example: https:&#x

More ›