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] AES-256- More NIST-y? paranoia
On 10/02/2013 02:13 PM, Brian Gladman wrote: The NIST specification only eliminated Rijndael options - none of the Rijndael options included in AES were changed in any way by NIST. Leaving aside the question of whether anyone weakened it, is it true that AES-256 provides comparable security to AES-128? Bear ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why is emailing me my password?
On 10/2/13 at 7:16 AM, g...@kinostudios.com (Greg) wrote: I'm interested in cases where Mailman passwords have been abused. Show me one instance where a nuclear reactor was brought down by an earthquake! Just one! Then I'll consider spending the $$ on it! And while you're at it, show me the cost of the abuse. Cheers - Bill - Bill Frantz| When it comes to the world | Periwinkle (408)356-8506 | around us, is there any choice | 16345 Englewood Ave www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why is emailing me my password?
On Wed, 2 Oct 2013 10:16:42 -0400 Greg g...@kinostudios.com wrote: I'm interested in cases where Mailman passwords have been abused. Show me one instance where a nuclear reactor was brought down by an earthquake! Just one! Then I'll consider spending the $$ on it! Assume for a moment that there are no other systems involved, and compare the failure of a nuclear power plant to a leaked mailman password. On its own, a failure at a nuclear power plant can render tens of thousands of square miles uninhabitable. On its own, a leaked mailman password causes a few minutes of annoyance. Really, the issue here is not mailman. Mailman passwords address a very minor security issue and mailing them in plaintext has no effect on said security. The real issue is that passwords are being used in places where security really does matter, and that someone might have used the same password for mailman as they did for one of those systems. If you ask me, the problem is not mailman sending out the passwords, nor the fact that people often use the same password everywhere; the problem is that passwords are being used to secure important things. -- Ben -- Benjamin R Kreuter UVA Computer Science brk...@virginia.edu KK4FJZ -- If large numbers of people are interested in freedom of speech, there will be freedom of speech, even if the law forbids it; if public opinion is sluggish, inconvenient minorities will be persecuted, even if laws exist to protect them. - George Orwell signature.asc Description: PGP signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] check-summed keys in secret ciphers?
Hi, Am 2013-09-30 10:16, schrieb ianG: I'm not really understanding the need for checksums on keys. Perhaps it is a DLP (Data Leakage Prevention) technology. At least the same method works great for Creditcard numbers. Oh, there is a 14 digit number being sent on a unclassified network, and all the checksums are correct? Someone is trying to leak ... terminate the connection, forensically analyze the machine, ... Best regards, Philipp ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?
On 2013-10-03 00:46, John Kelsey wrote: a. Most attacks come from protocol or mode failures, not so much crypto primitive failures. That is, there's a reaction attack on the way CBC encryption and message padding play with your application, and it doesn't matter whether you're using AES or FEAL-8 for your block cipher. The repeated failures of wifi are more crypto primitive failure, though underlying crypto primitives were abused in ways that exposed subtle weaknesses. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
Jerry Leichter leich...@lrw.com writes: My favorite more recent example of the pitfalls is TL1, a language and protocol used to managed high-end telecom equipment. TL1 has a completely rigorous syntax definition, but is supposed to be readable. For those not familiar with TL1, supposed to be readable here means encoded in ASCII rather than binary. It's about as readable as EDIFACT and HL7. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On 2013-10-02 23:09, Phillip Hallam-Baker wrote: No, the reason for baring multiple inheritance is not that it is too clever, it is that studies have shown that code using multiple inheritance is much harder for other people to understand than code using single inheritance.� That is because of the class of problems for which it is appropriate to use multiple inheritance. The original reason multiple inheritance was added to C was to support collections. Was it? And regardless of whether that was the reason, not what it is used for today. So I can't see where C++ is helping. It is reducing, not improving my productivity. C++ greatly improves my productivity, in particular the memory management classes std::unique_ptr and std::shared_ptr, though if using them means you have to use std::weak_ptr, then one has to pause and think. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?
On 2/10/13 17:46 PM, John Kelsey wrote: Has anyone tried to systematically look at what has led to previous crypto failures? This has been a favourite topic of mine, ever since I discovered that the entire foundation of SSL was built on theory, never confirmed in practice. But my views are informal, never published nor systematic. Here's a history I started for risk management of CAs, informally: http://wiki.cacert.org/Risk/History But I don't know of any general history of internet protocol breaches. That would inform us about where we need to be adding armor plate. My impression (this may be the availability heuristic at work) is that: a. Most attacks come from protocol or mode failures, not so much crypto primitive failures. That is, there's a reaction attack on the way CBC encryption and message padding play with your application, and it doesn't matter whether you're using AES or FEAL-8 for your block cipher. Most attacks go around the protocol, or as Adi to eloquently put it. Then, of the rest, most go against the software engineering outer layers. Attacks become less and less frequent as we peel the onion to get to the crypto core. However, it would be good to see an empirical survey of these failures, in order to know if my picture is accurate. b. Overemphasis on performance (because it's measurable and security usually isn't) plays really badly with having stuff be impossible to get out of the field when it's in use. Think of RC4 and DES and MD5 as examples. Yes. Software engineers are especially biased by this issue. Although, it rarely causes a breach, it more often distracts attention from what really matters. c. The ways I can see to avoid problems with crypto primitives are: (1) Overdesign against cryptanalysis (have lots of rounds) Frankly, I see this as a waste. The problem with rounds and analysis of same is that it isn't just one algorithm, it's many. Which means you are overdesigning for many algorithms, which means ... what? It is far better to select a target such as 128 bit security, and then design each component to meet this target. If you want overdesign then up the target to 160 bits, etc. And make all the components achieve this. The papers and numbers shown on keylength.com provide the basis for this. It's also been frequently commented that the NSA's design of Skipjack was balanced this way, and that's how they like it. Also note that the black-box effect in crypto protocols is very important. Once we have the black box (achieved par excellence by block ciphers and MDs) we can then concentrate on the protocol using those boxes. Which is to say that, because crypto can be black-boxed, then security protocols are far more of a software engineering problem than they are a crypto problem. (As you know, the race is now on to develop an AE stream black box.) Typically then we model the failure of an entire black box, as if it is totally transparent, rather than if it becomes weak. For example, in my payments work, I say what happens if my AES128 fails? Well, because all payments are signed by RSA204 then the attacker can simply read the payments, cannot make or inject payments. And the converse. This software engineering approach dominates questions such as AES at 128 level or 96 level, as it covers more attack surface area than the bit strength question. (2) Overdesign in security parameters (support only high security levels, use bigger than required RSA keys, etc.) As above. Perhaps the reason why I like a balanced approach is that, by the time that some of the components have started to show their age (and overdesign is starting to look attractive in hindsight) we have moved on *for everything*. Which is to say, it's time to replace the whole darn lot, and no overdesign would have saved us. E.g., look at SSL's failures. All (most?) of them were design flaws from complexity, none of them could be saved by overdesign in terms of rounds or params. So, overdesign can be seen as a sort of end-of-lifecycle bias of hindsight. (3) Don't accept anything without a proof reducing the security of the whole thing down to something overdesigned in the sense of (1) or (2). Proofs are ... good for cryptographers :) As I'm not, I can't comment further (nor do I design to them). iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] AES-256- More NIST-y? paranoia
I know others have already knocked this one down, but we are now in an area where conspiracy theories are real, so for avoidance of doubt... On 2/10/13 00:58 AM, Peter Fairbrother wrote: AES, the latest-and-greatest block cipher, comes in two main forms - AES-128 and AES-256. AES-256 is supposed to have a brute force work factor of 2^256 - but we find that in fact it actually has a very similar work factor to that of AES-128, due to bad subkey scheduling. This might relate to the related-key discoveries in 2009. Here's an explanation from Dani Nagy that might reach the non-cryptographer: http://financialcryptography.com/mt/archives/001180.html Thing is, that bad subkey scheduling was introduced by NIST ... after Rijndael, which won the open block cipher competition with what seems to be all-the-way good scheduling, was transformed into AES by NIST. So, why did NIST change the subkey scheduling? I don't think they did. Our Java code was submitted as part of the competition, and it only got renamed after the competition. No crypto changes that I recall. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ised
On 3/10/13 00:37 AM, Dave Horsfall wrote: On Wed, 2 Oct 2013, Jerry Leichter wrote: Always keep in mind - when you argue for easy readability - that one of COBOL's design goals was for programs to be readable and understandable by non-programmers. Managers, in particular. SQL, too, had that goal. 4GLs (remember them?). XML. Has it ever worked? iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] AES-256- More NIST-y? paranoia
On 03/10/2013 04:13, Ray Dillinger wrote: On 10/02/2013 02:13 PM, Brian Gladman wrote: The NIST specification only eliminated Rijndael options - none of the Rijndael options included in AES were changed in any way by NIST. Leaving aside the question of whether anyone weakened it, is it true that AES-256 provides comparable security to AES-128? I may be wrong about this, but if you are talking about the theoretical strength of AES-256, then I am not aware of any attacks against it that come even remotely close to reducing its effective key length to 128 bits. So my answer would be 'no'. But, having said that, I consider the use of AES-256 in place of AES-128 to be driven more by marketing hype than by reality. The theoreticaal strength of modern cryptographic algorithms is the least of our worries in producing practical secure systems. Brian Gladman ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] AES-256- More NIST-y? paranoia
On Oct 3, 2013, at 10:09 AM, Brian Gladman b...@gladman.plus.com wrote: Leaving aside the question of whether anyone weakened it, is it true that AES-256 provides comparable security to AES-128? I may be wrong about this, but if you are talking about the theoretical strength of AES-256, then I am not aware of any attacks against it that come even remotely close to reducing its effective key length to 128 bits. So my answer would be 'no'. There are *related key* attacks against full AES-192 and AES-256 with complexity 2^119. http://eprint.iacr.org/2009/374 reports on improved versions of these attacks against *reduced round variants of AES-256; for a 10-round variant of AES-256 (the same number of rounds as AES-128), the attacks have complexity 2^45 (under a strong related sub-key attack). None of these attacks gain any advantage when applied to AES-128. As *practical attacks today*, these are of no interest - related key attacks only apply in rather unrealistic scenarios, even a 2^119 strength is way beyond any realistic attack, and no one would use a reduced-round version of AES-256. As a *theoretical checkpoint on the strength of AES* ... the abstract says the results raise[s] serious concern about the remaining safety margin offered by the AES family of cryptosystems. The contact author on this paper, BTW, is Adi Shamir. But, having said that, I consider the use of AES-256 in place of AES-128 to be driven more by marketing hype than by reality. The theoreticaal strength of modern cryptographic algorithms is the least of our worries in producing practical secure systems. 100% agreement. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
For those not familiar with TL1, supposed to be readable here means encoded in ASCII rather than binary. It's about as readable as EDIFACT and HL7. utter_tangent The (U.S.) medical records system that started at the Veterans' Administration and has now spread to all but all parts of the U.S. Federal government that handle electronic health records is ASCII encoded, and readable. Called The Blue Button,[1] there is even an HL7-Blue Button file converter.[2] Score one for human readable. /utter_tangent --dan [1] www.va.gov/BLUEBUTTON/Resources.asp [2] www.hl7.org/implement/standards/product_brief.cfm?product_id=288 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On 2013-10-03 09:49, Peter Gutmann wrote: Jerry Leichter leich...@lrw.com writes: My favorite more recent example of the pitfalls is TL1, a language and protocol used to managed high-end telecom equipment. TL1 has a completely rigorous syntax definition, but is supposed to be readable. For those not familiar with TL1, supposed to be readable here means encoded in ASCII rather than binary. It's about as readable as EDIFACT and HL7. Then that puts it in the same category as HBCI version 1. Sure, it was rigorous. Sure, it was unambiguous. Sure, it was ASCII-encoded. But human-readable? I implemented that protocol once, and can assert that, after reading more HBCI messages than was probably good for me, I felt decidedly less than human. Fun, Stephan ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ised
On Thu, 3 Oct 2013, Peter Gutmann wrote: For those not familiar with TL1, supposed to be readable here means encoded in ASCII rather than binary. It's about as readable as EDIFACT and HL7. In a previous life I had to read, understand, and debug EDIFACT (it was OpenLDAP, as I recall). It wasn't all that difficult; then again, at one time I had to know APL\360 (once described as a write-only language). Want crypto? Try obscurity :-) -- Dave ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] AES-256- More NIST-y? paranoia
On Wed, Oct 2, 2013 at 8:13 PM, Ray Dillinger b...@sonic.net wrote: Leaving aside the question of whether anyone weakened it, is it true that AES-256 provides comparable security to AES-128? No, there's a common misconception that the related key attacks make AES-256 worse than AES-128 because AES-128 is not susceptible to these attacks. The alleged source of this information is a Bruce Schneier blog post (which is fine in and of itself, it's being misinterpreted). In Schneier et al's book Cryptography Engineering he recommends AES-256 over AES-128, despite the flaws, but suggests we might consider looking for a better cipher at this point. The rationale is that AES-256 still provides a wider security margin. -- Tony Arcieri ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ised
On Thu, Oct 3, 2013 at 5:19 AM, ianG i...@iang.org wrote: On 3/10/13 00:37 AM, Dave Horsfall wrote: On Wed, 2 Oct 2013, Jerry Leichter wrote: Always keep in mind - when you argue for easy readability - that one of COBOL's design goals was for programs to be readable and understandable by non-programmers. Managers, in particular. SQL, too, had that goal. 4GLs (remember them?). XML. Has it ever worked? XML was not intended to be easy to read, it was designed to be less painful to work with than SGML, that is all. There are actually good reasons why a document markup format needs to have more features than a protocol data encoding format. People tend to edit documents and need continuous syntax checks for a start. XML is actually a good document format and a lousy RPC encoding. Although that is exactly what SOAP is designed to turn XML into. The design of WSDL and SOAP is entirely due to the need to impedance match COM to HTTP. What does work in my experience is to design a language that is highly targeted at a particular problem set. Like building FSRs or LR(1) parsers or encoding X.509 certificates (this week's work). And no, an ASN1 compiler is not a particularly useful tool for encoding X.509v3 certs as it turns out. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] AES-256- More NIST-y? paranoia
On Oct 3, 2013, at 12:21 PM, Jerry Leichter leich...@lrw.com wrote: As *practical attacks today*, these are of no interest - related key attacks only apply in rather unrealistic scenarios, even a 2^119 strength is way beyond any realistic attack, and no one would use a reduced-round version of AES-256. Expanding a bit on what I said: Ideally, you'd like a cryptographic algorithm let you build a pair of black boxes. I put my data and a key into my black box, send you the output; you put the received data and the same key (or a paired key) into your black box; and out comes the data I sent you, fully secure and authenticated. Unfortunately, we have no clue how to build such black boxes. Even if the black boxes implement just the secrecy transformation for a stream of blocks (i.e., they are symmetric block ciphers), if there's a related key attack, I'm in danger if I haven't chosen my keys carefully enough. No protocol anyone is likely to use is subject to a related key attack, but it's one of those flaws that mean we haven't really gotten where we should. Also, any flaw is a hint that there might be other, more dangerous flaws elsewhere. If you think in these terms about asymmetric crypto, the situation is much, much worse. It turns out that you have to be really careful about what you shove into those boxes, or you open yourself up to all kinds of attacks. The classic paper on this subject is http://ieeexplore.ieee.org/xpl/login.jsp?tp=arnumber=4568385url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F4568363%2F4568364%2F04568385.pdf%3Farnumber%3D4568385, the text for which appears to available only for a fee. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
IMO readability is very hard to measure. Likely things being where you expect them to be, with minimal confusing characters but clear anchoring so you can start reading from anywhere. If someone could write a generative meta-language we can then ask people to do text comprehension tasks on the packed data. The relative speeds of completing those tasks should provide a measure of readability. I don't like anyone arguing about differences in readability without such empirical data. (it's all pretty similar unless you design against it I guess) XML is actually surprisingly readable. JSON is a lot more minimal. I find its restrictions frustrating and prefer using real JAVASCRIPT OBJECT NOTATION wherever possible, like INCLUDING FUNCTIONS and INCLUDING 'THIS' REFERENCES. Harder on parses, but why would you write your own anyway? (No, your language is not archaic/hipster enough not to have a parser for a popular notational format!) I think that's the most useful I have to say on the subject. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
