Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?
On 02/10/13 18:42, Arnold Reinhold wrote: On 1 Oct 2013 23:48 Jerry Leichter wrote: The larger the construction project, the tighter the limits on this stuff. I used to work with a former structural engineer, and he repeated some of the bad example stories they are taught. A famous case a number of years back involved a hotel in, I believe, Kansas City. The hotel had a large, open atrium, with two levels of concrete skyways for walking above. The skyways were hung from the roof. As the structural engineer specified their attachment, a long threaded steel rod ran from the roof, through one skyway - with the skyway held on by a nut - and then down to the second skyway, also held on by a nut. The builder, realizing that he would have to thread the nut for the upper skyway up many feet of rod, made a minor change: He instead used two threaded rods, one from roof to upper skyway, one from upper skyway to lower skyway. It's all the same, right? Well, no: In the original design, the upper nut holds the weight of just the upper skyway. In the m o di fied version, it holds the weight of *both* skyways. The upper fastening failed, the structure collapsed, and as I recall several people on the skyways at the time were killed. So ... not even a factor of two safety margin there. (The take-away from the story as delivered to future structural engineers was *not* that there wasn't a large enough safety margin - the calculations were accurate and well within the margins used in building such structures. The issue was that no one checked that the structure was actually built as designed.) This would be the 1981 Kansas City Hyatt Regency walkway collapse (http://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse) Which says of the original design: Investigators determined eventually that this design supported only 60 percent of the minimum load required by Kansas City building codes.[19], though the reference seems to be a dead link. (And as built it supported 30% or the required minimum.) So even if it had been built as designed, the safety margin would not have been well within the margins used in building such structures. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The hypothetical random number generator backdoor
On 23 September 2013 01:09, Phillip Hallam-Baker hal...@gmail.com wrote: So we think there is 'some kind' of backdoor in a random number generator. One question is how the EC math might make that possible. Another is how might the door be opened. Are you talking about http://en.wikipedia.org/wiki/Dual_EC_DRBG#Controversy or hypothetical RNGs in general, maybe not even EC based? I was thinking about this and it occurred to me that it is fairly easy to get a public SSL server to provide a client with a session key - just ask to start a session. For an RSA key exchange without ephemeral DH, the _client_ generates the premaster secret from which the session key is derived. However, ClientHello and ServerHello both contain random numbers sent before key exchange. If you are intercepting traffic, you have a nonce generated shortly before the session key generation for every key exchange, even without starting sessions of your own. Possibly you can use the client nonces to reduce the search space for the session keys (and if it's an RC4 session key, maybe the biases in RC4 help?). (Or, if using DHE, maybe it helps find DH private keys.) And possibly if you have server nonces based on the same PRNG seed as was used when the RSA key was generated, you can search for the RSA key. -- alan.bragg...@gmail.com http://www.chiark.greenend.org.uk/~armb/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA recommends against use of its own products.
On 24 September 2013 17:01, Jerry Leichter leich...@lrw.com wrote: On Sep 23, 2013, at 4:20 AM, ianG i...@iang.org wrote: ... But they made Dual EC DRBG the default ... At the time this default was chosen (2005 or thereabouts), it was *not* a mistake. https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html Problems with Dual_EC_DRBG were first described in early 2006 With hindsight, it was definitely a mistake. The questions are whether they could or should have known it was a mistake at the time and whether the NSA played any part in the mistake, and whether they should have warned users and changed the default well before now. -- alan.bragg...@gmail.com http://www.chiark.greenend.org.uk/~armb/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
