Re: [Cryptography] AES-256- More NIST-y? paranoia
On Thu, Oct 3, 2013 at 3:25 PM, leich...@lrw.com wrote: 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. This is complete and utter bullshit if you can count, or make big enough random numbers if you cannot. Read Cryptography in NaCl or Rogaway's analysis of authenticated encryption modes in standards if you don't believe this is a solved problem in theory, or heck, even the GCM or CCM standards. Or Rogaways OCB paper. 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. PRP security does not imply security in the related-key model. It also doesn't imply sPRP security. But you don't need it. Now, if you are making a claim about block cipher constructions, go show me why this matters by publishing an attack or some theoretical analysis about related keys leading to good attacks in a stronger setting. 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 Sincerely, Watson Ladd -- Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety. -- Benjamin Franklin ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On Thu, Oct 3, 2013 at 1:35 PM, Lodewijk andré de la porte l...@odewijk.nlwrote: 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!) What part of the Chomsky hierarchy do you not understand? What part of running computations on untrusted data which amount to Turing machines sounds like a good idea? The trivial DDOS, or the oh-so-amusing use as part of a distributed computing service? What dangers of multipass computation on potentially ambiguous data do you think are worth the extra connivence? And let's not forget the bugs that context-sensitive grammars invite. 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 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Sha3
On 10/1/2013 2:34 AM, Ray Dillinger wrote: What I don't understand here is why the process of selecting a standard algorithm for cryptographic primitives is so highly focused on speed. ~ What makes you think Keccak is faster than the alternatives that were not selected? My implementations suggest otherwise. I thought the main motivation for selecting Keccak was Sponge good. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
d...@geer.org writes: 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. Things like HL7 and EDIFACT/X12 (and ASN.1 in DER/BER form) were never meant to be human-readable, they're meant to be easily machine readable and processable. This is why you have viewers to turn them into human-readable form in any format you want. The problem with formats like XML is that it's never been quite sure what it wants to be, so that the result is neither easily human-readable nor easily machine-readable. Trying to get back on track, I think any attempt at TLS 2 is doomed. We've already gone through, what, about a million messages bikeshedding over the encoding format and have barely started on the crypto. Can you imagine any two people on this list agreeing on what crypto mechanism to use? Or whether identity-hiding (at the expense of complexity/security) should trump simplicity/security 9at the expense of exposing identity information)? Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ised
On 2013-10-04 09:33, Phillip Hallam-Baker wrote: The design of WSDL and SOAP is entirely due to the need to impedance match COM to HTTP. That is fairly horrifying, as COM was designed for a single threaded environment, and becomes and incomprehensible and extraordinarily inefficient security hole in a multi threaded environment. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
