3 ms·

>To help solve this serious issue, Enigma Bridge is proud to have developed a cost-effective, ground-breaking hardware security service which is based in the cl

>To help solve this serious issue, Enigma Bridge is proud to have developed a cost-effective, ground-breaking hardware security service which is based in the cloud. Uh huh. So https://dan.enigmabridge.com/re-investigating-the-origins-of-rsa-public-keys/ https://dan.enigmabridge.com/re-investigating-the-origins-of... has some more details, and the paper is at https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/svenda https://www.usenix.org/conference/usenixsecurity16/technical... It took me a couple of reads through the article to work out they're not necessarily talking about key strength, but fingerprinting the software / hardware that created the key in the first place.

djsumdog 10y ago
That's what I gathered, and it's not a huge deal unless a certain implementation is found to have a major bug. If a certain key generator is generating predictable or not-entirely-random keys and you can identify which system use those implementation, it can help script an attack vector.
- timv 10y ago
  > If a certain key generator is generating predictable or not-entirely-random keys and you can identify which system use those implementation, it can help script an attack vector Even then it's only relevant if fingerprinting makes the attack substantially easier that simply trying the exploit. Suppose that NastySSL 0.0.1 has a bug that reduces the strength of the keys it generates. If the bug (i.e. the reduction in strength) is significant, but not extreme, so that it takes about 48 hours of CPU time to break a key, then it would absolutely be useful to be able to fingerprint the keys produced by that tool. If, on the other hand, the bug is extreme, so that I can break keys in seconds (perhaps only in a subset of cases), then the fingerprinting might be helpful in saving me a few milliseconds, but it's not that big a deal. It's an interesting (but not overly surprising) line of research, and I expect that someone will find a way to make use of it in some sort of future attack vector, but it's hard to see an immediately obvious attack at face value.
terom 10y ago
> The main purpose of https ... Until now, it has been widely accepted ... No one expected that ... were supposed to be completely hidden from users as well as attackers. The worrying discovery .. > To help solve this serious issue, Enigma Bridge is proud to have developed a cost-effective, ground-breaking hardware security service which is based in the cloud This is just a FUD piece trying to sell their fancy cloud-based secure hype generator. Don't let your dirty hippie sysadmins use scary "Software standard use" methods like OpenSSL for key management! > ... whether companies think about the quality of their encryption keys or let their administrators use any tool at hand – instead of using secure hardware key generators > Use of validated secure hardware for key generation is the best approach to protect against many attacks. To be fair, some method for evaluating the security weaknesses in public keys (like blacklisting the weak Debian keys) is a good thing. I just take offense at this "custom secure hardware > standard software" thing.

djsumdog 10y ago

That's what I gathered, and it's not a huge deal unless a certain implementation is found to have a major bug. If a certain key generator is generating predictable or not-entirely-random keys and you can identify which system use those implementation, it can help script an attack vector.

timv 10y ago
> If a certain key generator is generating predictable or not-entirely-random keys and you can identify which system use those implementation, it can help script an attack vector Even then it's only relevant if fingerprinting makes the attack substantially easier that simply trying the exploit. Suppose that NastySSL 0.0.1 has a bug that reduces the strength of the keys it generates. If the bug (i.e. the reduction in strength) is significant, but not extreme, so that it takes about 48 hours of CPU time to break a key, then it would absolutely be useful to be able to fingerprint the keys produced by that tool. If, on the other hand, the bug is extreme, so that I can break keys in seconds (perhaps only in a subset of cases), then the fingerprinting might be helpful in saving me a few milliseconds, but it's not that big a deal. It's an interesting (but not overly surprising) line of research, and I expect that someone will find a way to make use of it in some sort of future attack vector, but it's hard to see an immediately obvious attack at face value.

terom 10y ago

> The main purpose of https ... Until now, it has been widely accepted ... No one expected that ... were supposed to be completely hidden from users as well as attackers. The worrying discovery .. > To help solve this serious issue, Enigma Bridge is proud to have developed a cost-effective, ground-breaking hardware security service which is based in the cloud This is just a FUD piece trying to sell their fancy cloud-based secure hype generator. Don't let your dirty hippie sysadmins use scary "Software standard use" methods like OpenSSL for key management! > ... whether companies think about the quality of their encryption keys or let their administrators use any tool at hand – instead of using secure hardware key generators > Use of validated secure hardware for key generation is the best approach to protect against many attacks. To be fair, some method for evaluating the security weaknesses in public keys (like blacklisting the weak Debian keys) is a good thing. I just take offense at this "custom secure hardware > standard software" thing.