Re: [Cryptography] IPv6 and IPSEC
On Tue, Sep 3, 2013 at 8:54 PM, Lucky Green shamr...@cypherpunks.to wrote: In its cryptic explanation of the bounces, Google makes one thing clear: whatever reason they have to bounce the email, that reason only applies to IPv6. I believe this is wrong. It only applies to IPv6 because applying it to IPv4 would break too many people. Not enough people use IPv6, so they are insisting on good hygiene there. Why do you not have PTR records for your IPv6 address? The problem is that, not Google's policy. -- Taral tar...@gmail.com Please let me know if there's any further trouble I can give you. -- Unknown ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Popular curves (was: NSA and cryptanalysis)
On 3/09/13 18:13 PM, Phillip Hallam-Baker wrote: The real issue is that the P-521 curve has IP against it, so if you want to use freely usable curves, you're stuck with P-256 and P-384 until some more patents expire. That's more of it than 192 bit security. We can hold our noses and use P-384 and AES-256 for a while. Jon What is the state of prior art for the P-384? When was it first published? Given that RIM is trying to sell itself right now and the patents are the only asset worth having, I don't have good feelings on this. Well apart from the business opportunities for expert witnesses specializing in crypto. The problem is that to make the market move we need everyone to decide to go in the same direction. So even though my employer can afford a license, there is no commercial value to that license unless everyone else has access. Do we have an ECC curve that is (1) secure and (2) has a written description prior to 1 Sept 1993? (Not answering your direct question.) Personally, I was happy to plan on using DJB's Curve25519. He's done the research and says it is good. Comments? Due to submarine patent potential, even that is not necessarily enough but it would be a start. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Hashes into Ciphers (was Re: FIPS, NIST and ITAR questions)
As a pure aside... On Tue, 3 Sep 2013 15:16:14 -0400 Faré fah...@gmail.com wrote: Can't you trivially transform a hash into a PRNG, a PRNG into a cypher, and vice versa? Phil Karn described a construction for turning any hash function into the core of a Feistel cipher in 1991. So far as I can tell, such ciphers are actually quite secure, though impractically slow. Pointers to his original sci.crypt posting would be appreciated, I wasn't able to find it with a quick search. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Hashes into Ciphers
On 4 September 2013 15:49, Perry E. Metzger pe...@piermont.com wrote: On Wed, 4 Sep 2013 10:37:12 -0400 Perry E. Metzger pe...@piermont.com wrote: Phil Karn described a construction for turning any hash function into the core of a Feistel cipher in 1991. So far as I can tell, such ciphers are actually quite secure, though impractically slow. Pointers to his original sci.crypt posting would be appreciated, I wasn't able to find it with a quick search. Answering my own question https://groups.google.com/forum/#!original/sci.crypt/tTWR2qIII0s/iDvT3ptY5CEJ Note that Karn's construction need not use any particular hash function -- he's more or less simply describing how to use a hash function of any sort as the heart of a Feistel cipher. His claim is that it is actually faster than DES, not impractically slow. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] FIPS, NIST and ITAR questions
On Tue, Sep 3, 2013 at 6:06 PM, Jerry Leichter leich...@lrw.com wrote: On Sep 3, 2013, at 3:16 PM, Faré fah...@gmail.com wrote: Can't you trivially transform a hash into a PRNG, a PRNG into a cypher, and vice versa? No. Let H(X) = SHA-512(X) || SHA-512(X) where '||' is concatenation. Assuming SHA-512 is a cryptographically secure hash H trivially is as well. (Nothing in the definition of a cryptographic hash function says anything about minimality.) But H(X) is clearly not useful for producing a PRNG. Just because it's trivial to produce bogus crypto doesn't mean it's non-trivial to produce good crypto, given a few universal recipes. IIUC, there are already good known ways to go from stream cipher to PRNG, or the other way around, and from a hash to a PRNG, and the other way around. e.g HMAC-DRBG goes hash to prng, the usual construct goes prng to stream cipher, and there's quite possibly a secure transform from cipher to hash, though I don't think the topic has been studied enough. All that to say, if digests are not subject to export, then it's easy to export crypto. Or conversely, if crypto is controlled, then it's easy for the thugs with badges to claim that digests are controlled, if they hate you. These techniques could also be used to produce cryptosystems that fit in very small source code and/or are the result of an automated search, so they may in practice defeat export restrictions and/or patent claims: just get the user to download it, libdvdcss style. That said, the missing piece currently seems to be good public key encryption. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org A child of five would understand this. Send someone to fetch a child of five. — Groucho Marx ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] FIPS, NIST and ITAR questions
On Wed, Sep 4, 2013 at 11:26 AM, Jerry Leichter leich...@lrw.com wrote: Just because it's trivial to produce bogus crypto doesn't mean it's non-trivial to produce good crypto, given a few universal recipes. Look, if you want to play around a produce things that look secure to you and a few of your buddies - feel free to go ahead. If your system is only used by you and a few friends, it's unlikely anyone with the appropriate skills will ever care enough to attack your system, and you'll be secure. As always, security is mainly an *economic* question, not a purely technical one. Jerry, if you have good reasons to believe that either HMAC-DRBG or the standard stream cipher construct are insecure, you should be publishing a paper, not flaming a nobody. That said, I readily admit that the cipher to hash transformation hasn't been widely studied enough, though there are real-world (enough) systems that use variants of such transformations, e.g. bcrypt. My main point was that for the sake of circumventing attempts to ban crypto, either through regulations or patents, you can bootstrap a pretty secure system out of a good hash function and simple transforms, that can probably all fit on a t-shirt together, either as APL or Perl gibberish or as a QR code. Good luck banning that. While this construct might not give you a best-of-breed system, especially with respect of performance or interoperability, it is good enough for Perry's purpose of bootstrapping a secure messaging system, and using such a system, can trivially bootstrap the best-of-breed system by downloading the missing bits. Now the thugs have to go sue millions of users. Sorry for repeating myself. I won't write on this topic anymore. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Anarchism is founded on the observation that since few men are wise enough to rule themselves, even fewer are wise enough to rule others. — Edward Abbey ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Three kinds of hash: Two are still under ITAR.
While doing some research on the history of hashing for a client I discovered that it is described in the very first edition of the ACM journal and the paper is a translation of a Russian paper. One of the many problems with the ITAR mindset is the assumption that all real ideas are invented inside the US by white men wearing white lab coats and that the rest of the undeserving world is stealing them. Anyone with any grasp of history recognizes that the industrial scale industrial espionage practiced by China on the industrial powers is merely DIY reparations for the 19th century and the first half of the 20th. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Hashes into Ciphers
On a more theoretical basis, Phil Rogaway gave a presentation at MIT many years ago where he showed the use of a one-way function as the construction primitive for every other type of symmetric algorithm. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Popular curves (was: NSA and cryptanalysis)
At 08:20 04/09/2013, ianG wrote: On 3/09/13 18:13 PM, Phillip Hallam-Baker wrote: Do we have an ECC curve that is (1) secure and (2) has a written description prior to 1 Sept 1993? (Not answering your direct question.) Personally, I was happy to plan on using DJB's Curve25519. He's done the research and says it is good. Comments? iang Curve25519 was designed for elliptic Diffie-Hellman taking care of both security and efficiency aspects and seems very strong in both of them. Some comments on its usage for other purposes can be found in http://stackoverflow.com/questions/2515948/use-of-curve25519 This curve was originally written for x86 32-bit platforms and a 64-bit implementation can be found in the following links: https://code.google.com/p/curve25519-donna/ https://github.com/agl/curve25519-donna In addition to this curve and to the NIST curves, another source for elliptic curves that can be (according to the developers) freely used is: http://certivox.org/display/EXT/CertiVox+Standard+Curves where cuves over 384 and 512-bit prime fields can be found which are likely secure. Of course, in all these cases you have to trust the curve developers somewhat although you can also check these curves for possible vulnerabilities. Alternatively, one can build one's own curve and for this one needs to have access to an implementation of the SEA point counting algorithm. A little while ago I was writing a cryptography book that uses Maple to implement both cryptographic schemes and cryptanalytic algorithms and, for a while, I contemplated the idea of programming SEA in Maple. However, I soon discarded it because there are already some freely available excelent implementations in compiled languages and my Maple implementation would necessarily be much slower. Thus, for some computations in the examples in my book I ended using MIRACL, a C/C++ library with excellent support for ECC which was recently adquired by CertiVox and can be found in the following links: http://www.certivox.com/miracl/ https://github.com/CertiVox/MIRACL Using the SEA algorithm one can readily find elliptic curves of prime order (or with a very small cofactor) which, additionally, can be tested to ensure that they satisfy some important conditions such as not having small embedding degree (to prevent the MOV reduction attack) or not having trace one (anomalous curves) which makes them also vulnerable. Of course, if the curves are (pseudo)randomly generated, it is very unlikely that they suffer from these vulnerabilities. Methods for verifiably random generation of such curves can be found in: http://www.secg.org/download/aid-780/sec1-v2.pdf and some recommended elliptic curves generated using these methods (including curves over 384-bit and 521-bit prime fields) are available from: http://www.secg.org/download/aid-784/sec2-v2.pdf Of course, I don't know whether these curves are completely free from IP concerns but, according to the sources where these curves are published, this seems to be the case (I am far from expert in the IP subject but, as a mathematician, the idea of someone owning an elliptic curve in some sense, seems to me very strange). Jose Luis. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Hashes into Ciphers
This first publication of differential cryptanalysis was at CRYPTO'90. I highly doubt Karn analyzed his construction relative to DC. (His post certainly makes no mention of it.) At first glance - I certainly haven't worked this through - it should be straightforward to construct a hash will all kinds of desirable *hash* properties that would, in Karn's construction, produce a cipher highly vulnerable to DC. (That is: This is not a safe *generic* construction, and I'm not sure exactly what requirements you'd have to put on the hash in order to be sure you got a DC-resistant cipher.) -- Jerry On Sep 4, 2013, at 10:49 AM, Perry E. Metzger pe...@piermont.com wrote: On Wed, 4 Sep 2013 10:37:12 -0400 Perry E. Metzger pe...@piermont.com wrote: Phil Karn described a construction for turning any hash function into the core of a Feistel cipher in 1991. So far as I can tell, such ciphers are actually quite secure, though impractically slow. Pointers to his original sci.crypt posting would be appreciated, I wasn't able to find it with a quick search. Answering my own question https://groups.google.com/forum/#!original/sci.crypt/tTWR2qIII0s/iDvT3ptY5CEJ Note that Karn's construction need not use any particular hash function -- he's more or less simply describing how to use a hash function of any sort as the heart of a Feistel cipher. Perry -- Perry E. Metzger pe...@piermont.com ___ 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] FIPS, NIST and ITAR questions
On Sep 4, 2013, at 10:45 AM, Faré fah...@gmail.com wrote: Can't you trivially transform a hash into a PRNG, a PRNG into a cypher, and vice versa? No. Let H(X) = SHA-512(X) || SHA-512(X) where '||' is concatenation. Assuming SHA-512 is a cryptographically secure hash H trivially is as well. (Nothing in the definition of a cryptographic hash function says anything about minimality.) But H(X) is clearly not useful for producing a PRNG. Just because it's trivial to produce bogus crypto doesn't mean it's non-trivial to produce good crypto, given a few universal recipes. Look, if you want to play around a produce things that look secure to you and a few of your buddies - feel free to go ahead. If your system is only used by you and a few friends, it's unlikely anyone with the appropriate skills will ever care enough to attack your system, and you'll be secure. As always, security is mainly an *economic* question, not a purely technical one. But if you want to play in the crypto game as it's actually played today - if you want something that will survive even if you use it to protect information that has significant value to someone willing to make the investment to get it from you - well, you're going to have to up your game. You're playing at 1980's levels. The world has moved on - your opponents won't feel constrained to do the same. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] IPv6 and IPSEC
On Sep 4, 2013 12:14 AM, Lucky Green shamr...@cypherpunks.to wrote: I *have* PTR records for my IPv6 addresses. What I don't know is which PTR records will make Gmail happy. SPF PTR records clearly do not do the trick. SPF uses TXT records, not PTR ones. Can you share your IPv6 address? I'll take a look. - JP ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] IPv6 and IPSEC
On Tue, Sep 03, 2013 at 10:27:14PM -0700, Taral wrote: On Tue, Sep 3, 2013 at 8:54 PM, Lucky Green shamr...@cypherpunks.to wrote: In its cryptic explanation of the bounces, Google makes one thing clear: whatever reason they have to bounce the email, that reason only applies to IPv6. I believe this is wrong. It only applies to IPv6 because applying it to IPv4 would break too many people. Not enough people use IPv6, so they are insisting on good hygiene there. Why do you not have PTR records for your IPv6 address? The problem is that, not Google's policy. I *have* PTR records for my IPv6 addresses. What I don't know is which PTR records will make Gmail happy. SPF PTR records clearly do not do the trick. --Lucky ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] IPv6 and IPSEC
On Wed, 4 Sep 2013 09:14:36 +0200 Lucky Green shamr...@cypherpunks.to wrote: I *have* PTR records for my IPv6 addresses. What I don't know is which PTR records will make Gmail happy. SPF PTR records clearly do not do the trick. I think this conversation has, at this point, gone well beyond the scope of the list. There are a bunch of google people on the mailing list, perhaps one or more of them might want to contact Lucky in private and see if they can help him with his question. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Hashes into Ciphers
On Wed, 4 Sep 2013 10:37:12 -0400 Perry E. Metzger pe...@piermont.com wrote: Phil Karn described a construction for turning any hash function into the core of a Feistel cipher in 1991. So far as I can tell, such ciphers are actually quite secure, though impractically slow. Pointers to his original sci.crypt posting would be appreciated, I wasn't able to find it with a quick search. Answering my own question https://groups.google.com/forum/#!original/sci.crypt/tTWR2qIII0s/iDvT3ptY5CEJ Note that Karn's construction need not use any particular hash function -- he's more or less simply describing how to use a hash function of any sort as the heart of a Feistel cipher. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Hashes into Ciphers (was Re: FIPS, NIST and ITAR questions)
On 2013-09-04 16:37, Perry E. Metzger wrote: Phil Karn described a construction for turning any hash function into the core of a Feistel cipher in 1991. So far as I can tell, such ciphers are actually quite secure, though impractically slow. Pointers to his original sci.crypt posting would be appreciated, I wasn't able to find it with a quick search. I remember having reviewed a construction by Peter Gutmann, called a Message Digest Cipher, at around that time, which also turned a hash function into a cipher. I do remember that at that time I thought it was quite secure, but I was just a little puppy then. Schneier reviews this construction in Applied Cryptography and can't find fault with it, but doesn't like it on principle (using the hash function for something for which it is not intended). It works like this. Let h be the incremental hash function, i.e., the compression function that you use to hash data piecewise. In programming terms, this function is usually called XXXUpdate() if XXX is the name of the hash function. Then, if P(1), ..., P(n) are your plaintext blocks and K is your key, compute: C(1) = P(1) XOR h(IV, K) C(j) = P(j) XOR h(C(j-1), K), for 1 j = n. Decryption is a very similar operation: P(1) = C(1) XOR h(IV, K) P(j) = C(j) XOR h(C(j-1), K), for 1 j = n. It's just running the compression function in CFB mode. Fun, Stephan ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] FIPS, NIST and ITAR questions
At 03:06 PM 9/3/2013, Jerry Leichter wrote: On Sep 3, 2013, at 3:16 PM, Faré fah...@gmail.com wrote: Can't you trivially transform a hash into a PRNG, a PRNG into a cypher, and vice versa? No. [...] I don't actually know if there exists a construction of a PRNG from a cryptographically secure hash function. (You can build a MAC, but even that's not trivial; people tried all kinds of things that failed until the HMAC construction was proven correct.) PRNG is not necessarily a cryptographically strong term. But isn't counter-mode hash likely to be ok? Counter = seed; while (counter++) Output(Hash(counter)); // or as somebody said Output(Hash(seed||counter||seed)); // and you probably need to pad it to be long enough for the hash to be happy. Obviously if somebody discovers the seed the whole thing is toast. And you can turn the PRNG into a stream cypher by doing plaintext[x] xor PRNG[x], with the usual limitations. None of that has any bearing on ITAR, of course. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Google's Public Key Size (was Re: NSA and cryptanalysis)
On Mon, Sep 2, 2013 at 3:04 PM, Jeffrey I. Schiller j...@mit.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Sep 02, 2013 at 03:09:31PM -0400, Jerry Leichter wrote: Google recently switched to 2048 bit keys; hardly any other sites have done so, and some older software even has trouble talking to Google as a result. Btw. As a random side-note. Google switched to 2048 bit RSA keys on their search engine. However my connection to mail.google.com is using a NIST p256r1 ECC key in its certificate. As of Jan-2014 CAs are forbidden from issuing/signing anything less than 2048 certs. Lots of people are acting now to get ahead of that. EV's have been required to be 2048 for quite some time. - Andy ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
