4 ms·
This is almost certainly not true given the fact that ECDRBG is chronically slow (think orders of magnitude). Any developers working on implementations which g
by healsjnr1 13y ago
This is almost certainly not true given the fact that ECDRBG is chronically slow (think orders of magnitude). Any developers working on implementations which generate a reasonable amount of random data switch to HMAC very quickly.
- acqq 13y agoSo "it's not true that companies who use default use default because if they use default they will measure the speed and then not use default?" Too much reading Catch 22? In fact, the companies who use default simply use it. Period. And they use default in spite of it being slower than something else.
- healsjnr1 13y agoI think that's a very long bow to draw... Especially seeing as the trouble shooting guide for bsafe libraries has a section dedicated to speeding up the toolkit which advises switching to HMAC. I'm not sure about you, but when I see a chronic change in performance I look into it, and if there is a vendor recommended suggestion, I usually try it. This is particularly true for the Java tools as it is trivial in the extreme to compare the bsafe performance with the standard oracle crypto performance. Basically, as tptacek points out, there is a lot of information we aren't privy to and there is no point assuming every bsafe customer is using ec .
- acqq 13y agoWhen the company uses the default in the product, it uses it. There's nothing "to draw." It's a true statement, not a hypothesis. And it has nothing to do with what you do when you "see a chronic change in performance." If somebody uses something and not something else, there's no "change" at all. Nobody ever claimed "every customer uses Dual_EC." The claim is: there are a lot of famous customers and products using BSAFE and the Dual_EC is the default in BSAFE. Interestingly, Dual_EC can still be negotiated in other implementations too. Poisoning the standards sets leaves some possibilities as long as the dangerous implementations are present.
- tptacek 13y agoThe big problem with the claim that "lots of famous customers and products use BSAFE" is that the statement by itself doesn't mean much. Does BSAFE provide the TLS library for Cisco IOS? Neither of us probably has a ready answer, but if you'd like to put some money on which way this will go, I'm game. For awhile during the late 1990s, some products used BSAFE because there were patent concerns with using any public key encryption in a commercial product, and BSAFE was an innoculation. Also, some products have codebases that date back before credible open-source crypto libraries. But those same products tend to have crypto features that were implemented later. Like I said, we do a lot of casual reversing, and we look at a lot of random products that big F500 companies deploy, because F500s pay us to do that. I see a lot of OpenSSL. After that, I see a lot of Windows Cryptography API. Next in line is probably cryptopp, and then Bouncycastle. I see BSAFE once in a blue moon. The more I think about it, the more interesting the research project of working out exactly why different products depend or don't depend on BSAFE actually starts to sound.
- chopin 13y agoThis is interesting in that regard: http://dualec.org/ http://dualec.org/. If this research is true, it seems that a number of servers use it.