Re: [cryptography] 100 Gbps line rate encryption
On 7/16/13 11:15 AM, Matthew Green wrote: http://www.isg.rhul.ac.uk/tls/RC4biases.pdf Thanks for bringing this pre-print link to my attention! In summary, don't use RC4. Don't use it carelessly with IVs. And don't use RC4. RC4 is available in many libraries and platforms. For the immediate future, it is most easily and likely implemented. We need something yesterday, not next year. So, that's one of the options being explored. All I'm trying to cover is doing it as securely as possible. (As I've some experience with this, you can rest assured that I've a fair understanding of IVs and other mechanics.) Consider using Salsa20 instead. It would be helpful for folks to read the entire thread before making off the wall comments. Yes, folks have mentioned Salsa20. It doesn't seem as amenable to PPP packets as I would like. But as I was looking at it, is seemed he'd moved on to ChaCha. I'm behind the times on this So, let's talk about what to choose for something fast and modern to implement in the next decade We cannot recommend a dozen EU possibilities. We need something that's already had some significant analysis. Salsa20 or ChaCha? Discuss. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
[2013-07-17, William Allen Simpson] On 7/16/13 11:15 AM, Matthew Green wrote: Consider using Salsa20 instead. It would be helpful for folks to read the entire thread before making off the wall comments. Yes, folks have mentioned Salsa20. It doesn't seem as amenable to PPP packets as I would like. But as I was looking at it, is seemed he'd moved on to ChaCha. I'm behind the times on this So, let's talk about what to choose for something fast and modern to implement in the next decade We cannot recommend a dozen EU possibilities. We need something that's already had some significant analysis. Salsa20 or ChaCha? Discuss. Salsa20/12 or /20. Not because there's anything wrong with the ChaCha variant, but because Salsa20 is good enough and also better established. Note e.g. that Salsa20 is what's used in NaCl [1] (released well after ChaCha was proposed). Regarding ESTREAM, disregard the hardware ciphers in the final portfolio. That limits the number of algorithms to four. Of these, I think Salsa20 is the only one that has obtained significant adoption. However, if I were to pick another, I'd be partial to HC-128 due to its simple (somewhat RC4-like) design and very impressive software performance. Cheers, Tor [1] http://nacl.cr.yp.to/stream.html ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
Hi Bill, On 17/07/13 10:50 AM, William Allen Simpson wrote: Yes, folks have mentioned Salsa20. It doesn't seem as amenable to PPP packets as I would like. I don't quite know what that means, but reading quickly: http://tools.ietf.org/html/draft-simpson-ppp-arc4-00 it seems you are doing the same things as I and Zooko did a while ago with what we termed SDP1. That is, a huge secret key shared previously (out of scope) was used for key, IV and HMAC needs. Thing is, you don't just need an encryption algorithm, you also need IV, MAC, Padding concepts. (I agree that using a stream cipher obviates any messing Padding needs and the 'mode' choice.) FWIW, I'm planning on replacing my SDP1 in time with DJB's design for Curve25519XSalsa20Poly1305, in part because his thinking is so happily aligned -- one true cipher suite, comprehensively designed with great thought to integrate all needs, to last for a long time. But as I was looking at it, is seemed he'd moved on to ChaCha. I'm behind the times on this He's an academic, he hasn't so much 'moved on' as published another paper with a slight variation ;-) So, let's talk about what to choose for something fast and modern to implement in the next decade IMO, you should precisely recommend one complete suite and only one. We cannot recommend a dozen EU possibilities. We need something that's already had some significant analysis. Salsa20 or ChaCha? Discuss. Some random comments. I suspect that Salsa20 is still a more recommended thing, even by DJB. In his one true crypto suite above (he calls it a cryptobox) he uses it (or a variant/extension called XSalsa). Salsa20 has also had 8 or so years academic scrutiny sparked by eStream. (In the alternate, the differences between ChaCha and Salsa is pretty slim, you could conceivably change that over at a late stage without upsetting much demo implementation work. https://en.wikipedia.org/wiki/Salsa20#ChaCha_variant ) Implementing Salsa isn't so hard, most popular languages are done, and there are test vectors from eStream [0]. I got the test vectors basically working in a few hours of work, using an implementation I found on the net. If you are working at the RFC level then I'd suggest it is better to look forward and choose a modern suite. Especially, as people haven't even started implementing as yet ... the cost difference between Salsa 20 and ARC4 *in implementation of the overall protocol* is going to be trivial at this stage. A competent cryptoblumber should be able to port in a weekend. Also, IMHO, you are going to face a credibility barrier with ARC4, which you will not face with Salsa20. In short, ARC4 doesn't pass the cryptographer's laugh test. While you might not care (and frankly your target market might even support a lightweight protection) you will find it easier to get help in deployment if implementors respect the choice of cryptosuite. iang [0] I haven't found them for XSalsa as yet. Don't know about ChaCha. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
[0] I haven't found them for XSalsa as yet. Don't know about ChaCha. They are both included in http://bench.cr.yp.to/primitives-stream.html with reference implementations and efficient implementaiton. The supercop test framework (downloadable from eBACS) checks other implementations against the reference implementation. This is better than test vectors in catching errors. Tanja ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
On Wed, Jul 17, 2013 at 7:42 AM, ianG i...@iang.org wrote: On 17/07/13 10:50 AM, William Allen Simpson wrote: Thing is, you don't just need an encryption algorithm, you also need IV, MAC, Padding concepts. (I agree that using a stream cipher obviates any messing Padding needs and the 'mode' choice.) Choices for dealing with padding: - accept padding - use a stream cipher - use a counter cipher mode (not unlike a stream cipher) - use ciphertext stealing modes Kerberos uses CTS for AES, but it's proven to be painful. My advice: accept the padding. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
On 17 July 2013 08:50, William Allen Simpson william.allen.simp...@gmail.com wrote: In summary, don't use RC4. Don't use it carelessly with IVs. And don't use RC4. RC4 is available in many libraries and platforms. For the immediate future, it is most easily and likely implemented. We need something yesterday, not next year. So is Salsa20, for that matter you have optimised versions available in NaCl, etc. So, that's one of the options being explored. All I'm trying to cover is doing it as securely as possible. Then RC4 is not the way to go, especially when you're starting off with anything standardisation shaped. (As I've some experience with this, you can rest assured that I've a fair understanding of IVs and other mechanics.) Consider using Salsa20 instead. It would be helpful for folks to read the entire thread before making off the wall comments. Yes, folks have mentioned Salsa20. It doesn't seem as amenable to PPP packets as I would like. But as I was looking at it, is seemed he'd moved on to ChaCha. I'm behind the times on this You're rekeying RC4 every packet and having to construct an do-it-yourself IV scheme, that doesn't seem particularly amenable to begin with. So, let's talk about what to choose for something fast and modern to implement in the next decade We cannot recommend a dozen EU possibilities. We need something that's already had some significant analysis. Salsa20 or ChaCha? Discuss. Salsa20, you can choose one of the faster variants. If you're not wanting encryption for appearances sake - and your phrase securely as possible above indicates that - you may also want to consider a MAC... again these days you have easy(ish) options. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
On Wed, Jul 17, 2013 at 03:50:50AM -0400, William Allen Simpson wrote: On 7/16/13 11:15 AM, Matthew Green wrote: http://www.isg.rhul.ac.uk/tls/RC4biases.pdf Thanks for bringing this pre-print link to my attention! In summary, don't use RC4. Don't use it carelessly with IVs. And don't use RC4. RC4 is available in many libraries and platforms. For the immediate future, it is most easily and likely implemented. So is single-DES. Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
William Allen Simpson william.allen.simp...@gmail.com wrote: We need something yesterday, not next year. ... Yes, folks have mentioned Salsa20. ... So, let's talk about what to choose for something fast and modern to implement in the next decade We cannot recommend a dozen EU possibilities. We need something that's already had some significant analysis. Salsa20 or ChaCha? Discuss. There are only seven EU possibilities and all of them got significant analysis during the competition. If you want a cipher for hardware implementation, there are three choices. For software, four including Salsa. Pick one away you go, -- Who put a stop payment on my reality check? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] authentication protocol proposal
hello, admittedly, i got a little bit hyped about Keccak, especially its versatility. so i thought why not devise an authenitcation / key stretching / key derivation / secure storage protocol that uses solely Keccak to achieve all of its goals? i put together a brief (5 page) document describing the protocol itself: https://docs.google.com/document/d/1kq6f3o-30ao7Dq4CGvBYL0SwzqdSNU0t4JN3r-7kdfk some benefits: * all operations can be identified with single (multiphase) Keccak operation * any amount of data can be derived, and it is not costly (unlike PBKDF2) * through a session key, data can be derived at a later time * uses only one crypto primitive * extremely simple * grants access to many kinds of primitives (prng, stream cipher, MAC) with the notable exception of a block cipher. * up to 127 character passwords with 128 bit salt * designed to be compatible with 3rd party Keccak libraries, though not with SHA-3 only libraries so if you got hyped about Keccak too, you might want to have a looksie. any feedback is appreciated. regs, Krisztián ps: references to Kerckhoff are not necessary. i know the drill. it is a discussion. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] authentication protocol proposal
Subject [cryptography] authentication protocol proposa For authentication of what/whom, with what credentials, to what target(s)? Ah, users with passwords to some node with a password verifier. On Wed, Jul 17, 2013 at 4:54 PM, Krisztián Pintér pinte...@gmail.com wrote: hello, some benefits: [...] * any amount of data can be derived, and it is not costly (unlike PBKDF2) [...] Well, so in general we want PBKDFs to be slow and require lots of RAM as a defense against off-line password attacks on stolen password verifiers. Once you have a session key you should want to use a KDF, not a PBKDF, because you need the KDF to be fast. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
On 7/17/13 4:29 AM, Tor Erling Bjørstad wrote: Salsa20/12 or /20. Not because there's anything wrong with the ChaCha variant, but because Salsa20 is good enough and also better established. Note e.g. that Salsa20 is what's used in NaCl [1] (released well after ChaCha was proposed). Thank you (to all who mentioned this). Good information. Regarding ESTREAM, disregard the hardware ciphers in the final portfolio. That limits the number of algorithms to four. Of these, I think Salsa20 is the only one that has obtained significant adoption. However, if I were to pick another, I'd be partial to HC-128 due to its simple (somewhat RC4-like) design and very impressive software performance. [1] http://nacl.cr.yp.to/stream.html And there's HC-256, according to wikipedia. But what about independent analysis? And is it really faster? Salsa20: 4–14 cycles per byte HC-256: 4 cycles per byte. HC-128: 3 cycles per byte. But HC-* has a huge per packet setup penalty!?!? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
