11–20 of 143 posts
Earlier quoted context omitted.
True. 2^63 and 2^64 are effectively the same cost to break. Instead of costing $2X to break, it now costs $X.
when X > $1M (maybe even large) it really doesn't
The reason CAs are required to use 64-bit serial numbers is to make the content of a certificate hard to guess, which provides better protection against hash collisions. IIRC this policy was introduced when certs were still signed using MD5 hashes. (That or shortly after it was retired.) Since all publicly-trusted certs use SHA256 today, the actual security impact of this incident is practically nil.
> As demonstrated in https://events.ccc.de/congress/2008/Fahrplan/attachments/125..., hash collisions can allow an attacker to forge a signature on the certificate of their choosing. The birthday paradox means that, in the absence of random bits, the security level of a hash function is half what it should be. Adding random bits to issued certificates mitigates collision attacks and means that an attacker must be capable of a much harder preimage attack. For a long time the Baseline Requirements have encouraged adding random bits to the serial number of a certificate, and it is now common practice. This ballot makes that best practice required, which will make the Web PKI much more robust against all future weaknesses in hash functions. Additionally, it replaces “entropy” with “CSPRNG” to make the requirement clearer and easier to audit, and clarifies that the serial number must be positive.
The 'pull the certificates from the browsers' thing demands people from these companies maybe recuse themselves from conversations?
(this is public trust process stuff, not technology per se)
Sooooo all the big players depend on one CA PKI package: EJBCA - is that not a major concern ?
Just to be clear - "mississued" in this case doesn't mean they were issued to someone who doesn't control the domain. The issue is they were issued using a 63-bit serial number instead of the minimum 64 bits. (The software these CAs were all using was generating 64 random bits, but setting the first bit to zero to produce a positive integer.) The reason CAs are required to use 64-bit serial numbers is to make the con…
Sooooo all the big players depend on one CA PKI package: EJBCA - is that not a major concern ?
Typically with crypto you want to stick with one major industry standard implementation that is strenuously verified. It's probably more concerning if everyone's using their own.
Seems like a lot of hand wringing over nothing, security is done with huge factors of safety (moving to 256 bit keys when no one had ever broken a 128 or even 96 bit key). It's hard to imagine that 1,2, or even a quarter of the bits couldn't be zero-ed. > it’s easy to think that a difference of 1 single bit would be largely inconsequential when considering numbers this big. In fact, he said, the difference between 26…
Serials were originally intended for... well, for multiple purposes. But if they only function today as a random nonce, and if they're already 65 bits, then they may as well be 128 bits or larger.
A randomly generated 64-bit nonce has a 50% chance of repeating after 2^32 iterations. That can be acceptable, especially if you can rely on other certificate data (e.g. issued and expire timestamps) changing. But such expectations have a poor track record which you don't want to rely on unless your back is against the wall (e.g. as in AES GCM). Because certificates are already so large, absent some dubious backwards compatibility arguments I'm surprised they just didn't require 128-bit serials.