Re: [cryptography] 100 Gbps line rate encryption
On 7/18/13 4:36 AM, Tor Erling Bjørstad wrote: What makes HC-* interesting to me is that it's pretty much as fast as one gets it, for a strong pure software cipher encrypting long streams of data. If one has a limited number of data streams that are pushing a huge number of bits over the wire, HC-* seems pretty appealing. If the use-case instead involves a zillion independent short packets that all need to be encrypted with a unique key/IV combo, then HC's performance will indeed suck. It's the perennial problem that cryptographers design for theoretical scenarios. That's why it's better not to let them design net protocols. The average packet used to be 41 bytes. I think I read its now ~43 bytes, but even the average HTTP GET is ~600 bytes. Did they define operating for an actual traditional longer-term key with a per packet IV? If not, I'll just use my usual one. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
[2013-07-18, William Allen Simpson] >On 7/17/13 4:29 AM, Tor Erling Bjørstad wrote: >>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: 414 cycles per byte > >HC-256: 4 cycles per byte. >HC-128: 3 cycles per byte. > >But HC-* has a huge per packet setup penalty!?!? There was a fair amount of attention on HC from the international research community during the ESTREAM competition (2005-2008). Most of it didn't lead very far, and probably remains unpublished or lost [1]. The findings that have been made public are all pretty minor. Certainly the two HC variants haven't received the kind of attention that the SHA-3 finalists (or Salsa20, for that matter) has, but it is also clear that researchers have been spending a not insignificant amount of brainpower trying to break it. Whether that's "sufficient" analysis for some particular use-case is hard to quantify. What makes HC-* interesting to me is that it's pretty much as fast as one gets it, for a strong pure software cipher encrypting long streams of data. If one has a limited number of data streams that are pushing a huge number of bits over the wire, HC-* seems pretty appealing. If the use-case instead involves a zillion independent short packets that all need to be encrypted with a unique key/IV combo, then HC's performance will indeed suck. Cheers, Tor [1] I spent some time on cryptanalysis of HC at one point, and I also remember working on it in a larger group at some of the meetings in Leuven. The only notable result coming our of those efforts, was that all our ideas were totally busted [2]. [2] This is, of course, the default outcome from cryptanalysis. ___ 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
Re: [cryptography] 100 Gbps line rate encryption
William Allen Simpson 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
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
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 7:42 AM, ianG 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
> [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
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
[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
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
Matthew Green writes: >In summary, don't use RC4. Don't use it carelessly with IVs. And don't use >RC4. The first rule of RC4 club is... Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
The use of RC4 should be avoided even with the drop-N due to biases that occur later in the key stream. You should also be extremely careful about mixing IVs with the key. At a minimum you ought to use a modern cryptographic hash function -- there's no evidence that repeating key setup is sufficient to prevent correlations. http://www.isg.rhul.ac.uk/tls/RC4biases.pdf In summary, don't use RC4. Don't use it carelessly with IVs. And don't use RC4. Consider using Salsa20 instead. Matt On Jul 16, 2013, at 10:43 AM, Thor Lancelot Simon wrote: > On Tue, Jul 16, 2013 at 03:23:01AM -0400, William Allen Simpson wrote: >> On 6/22/13 8:24 PM, Greg Rose wrote: >>> >>> On Jun 22, 2013, at 15:31 , James A. Donald wrote: >>> On 2013-06-23 6:47 AM, Peter Maxwell wrote: > I think Bernstein's Salsa20 is faster and significantly more secure than > RC4, whether you'll be able to design hardware to run at line-speed is > somewhat more questionable though (would be interested to know if it's > possible right enough). I would be surprised if it is faster. >>> >>> Be surprised, then... almost all of the recent word- or block- oriented >>> stream ciphers are faster than RC4. And NOTHING should still be using RC4; >>> by today's standards it is quite insecure. >> So I spent some (much too much) time reading old PPP archives on our >> earlier discussions selecting an algorithm. Sadly, 3DES was chosen, >> but rarely implemented. >> >> I cobbled together a draft based on old discussion for ARC4. It >> surely needs more work. Although (as you mention) that's old stuff, >> it has the advantage of having running code in most existing systems, >> and could be rolled out quickly on high speed connections. >> >> http://tools.ietf.org/html/draft-simpson-ppp-arc4-00 > > If you're really going to publish a new RFC -- even an Experimental > one -- using RC4, you should really use RC4-drop-N. For even moderately > sized packets and reasonable values of N, if you effectively rekey every > packet, you will end up wasting 25-50% of the throughput of the system. > > Conclusion: RC4 is particularly poorly suited for this application > in the modern day. > > Thor > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
William Allen Simpson wrote: > A quick question: what are our current options for 100 Gbps > line rate encryption? > > Are we still using variants of ARC4? The European Union's Estream contest gave two small portfolios of ciphers, four for software implementation and three for hardware. That is the first place I'd look. http://www.ecrypt.eu.org/stream/index.html -- Who put a stop payment on my reality check? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
On Tue, Jul 16, 2013 at 03:23:01AM -0400, William Allen Simpson wrote: > On 6/22/13 8:24 PM, Greg Rose wrote: > > > >On Jun 22, 2013, at 15:31 , James A. Donald wrote: > > > >>On 2013-06-23 6:47 AM, Peter Maxwell wrote: > >>>I think Bernstein's Salsa20 is faster and significantly more secure than > >>>RC4, whether you'll be able to design hardware to run at line-speed is > >>>somewhat more questionable though (would be interested to know if it's > >>>possible right enough). > >> > >>I would be surprised if it is faster. > > > >Be surprised, then... almost all of the recent word- or block- oriented > >stream ciphers are faster than RC4. And NOTHING should still be using RC4; > >by today's standards it is quite insecure. > > > So I spent some (much too much) time reading old PPP archives on our > earlier discussions selecting an algorithm. Sadly, 3DES was chosen, > but rarely implemented. > > I cobbled together a draft based on old discussion for ARC4. It > surely needs more work. Although (as you mention) that's old stuff, > it has the advantage of having running code in most existing systems, > and could be rolled out quickly on high speed connections. > > http://tools.ietf.org/html/draft-simpson-ppp-arc4-00 If you're really going to publish a new RFC -- even an Experimental one -- using RC4, you should really use RC4-drop-N. For even moderately sized packets and reasonable values of N, if you effectively rekey every packet, you will end up wasting 25-50% of the throughput of the system. Conclusion: RC4 is particularly poorly suited for this application in the modern day. Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
On 6/22/13 8:24 PM, Greg Rose wrote: On Jun 22, 2013, at 15:31 , James A. Donald wrote: On 2013-06-23 6:47 AM, Peter Maxwell wrote: I think Bernstein's Salsa20 is faster and significantly more secure than RC4, whether you'll be able to design hardware to run at line-speed is somewhat more questionable though (would be interested to know if it's possible right enough). I would be surprised if it is faster. Be surprised, then... almost all of the recent word- or block- oriented stream ciphers are faster than RC4. And NOTHING should still be using RC4; by today's standards it is quite insecure. So I spent some (much too much) time reading old PPP archives on our earlier discussions selecting an algorithm. Sadly, 3DES was chosen, but rarely implemented. I cobbled together a draft based on old discussion for ARC4. It surely needs more work. Although (as you mention) that's old stuff, it has the advantage of having running code in most existing systems, and could be rolled out quickly on high speed connections. http://tools.ietf.org/html/draft-simpson-ppp-arc4-00 I was attempting a draft for Salsa20, then discovered there's a successor called ChaCha. Since I didn't also have enough time to investigate (and it wasn't mentioned here), I held off pushing out the Salsa20 draft. But I'd like to have something more modern in the pipeline. Please discuss. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
Are you assuming a single core? I ran 'openssl speed' on an 8-core 2.9 GHz Intel Xeon E5-2690 with hyperthreading enabled, which gives it 16 logical cores. It's an artificial benchmark, but openssl is able to encrypt using AES-XTS with 128-bit keys at 28 gigabytes / second for 8KB blocks, which is 225.2 gigabits per second. This may not be relevant to the whichever platforms the original post was thinking of. On the x86 platform I tested this on, memory bandwidth would be the bottleneck before the crypto. Edited output: $ uname -a Linux [hostname] 3.2.0-41-generic #66-Ubuntu SMP Thu Apr 25 03:27:11 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux $ openssl speed -multi 16 -evp aes-128-xts OpenSSL 1.0.1 14 Mar 2012 built on: Mon Apr 15 15:27:18 UTC 2013 [some build output omitted] The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes evp3994884.76k 11902064.66k 21140865.02k 26338644.65k 28151824.38k On Sun, Jun 30, 2013 at 2:13 PM, wrote: > Oops, miscalculation. That should be a 6.5 Ghz clock for 100 Gbps. ((100 > Gbps/8)/2) . Anyway I don't think anybody has hardware that fast except > maybe for IBM with the Power8. > > > The fastest hardware implementation of RC4 that I know is 2 bytes/clock. > I > > personally programmed a 1 byte/clock RC4 in a FPGA, it's quite simple. > > > > At 2 bytes/clock you still need a clock of 10 gigahertz to encrypt 100 > > Gbps. That's unfeasible, the way it's done is using paralelism, then you > > can use any algorithm you want as long as you have silicon available. > > Consider there are 400 Gbps systems coming online. > > > > Using a PC for that kind of workload is a waste of money and power. FPGAs > > are not that expensive nowadays. > > > > > > > > > >> Just as a data point, on x86 processors with AESNI you can encrypt AES > >> in, > >> say, XTS mode with about 0.75 cycles / byte on each core. > >> > >> On an Intel Xeon E5-2690 'openssl speed -multi 4 -evp aes-128-xts' tops > >> out > >> at 13.5 GB/s for 8k blocks, which is 108 Gbps. That's only using half > >> the > >> physical cores and no hyperthreading. > >> > >> However, that's unlikely a realistic benchmark for whatever context the > >> original question was referring to. > >> > >> > >> On Sat, Jun 22, 2013 at 5:25 PM, Peter Maxwell > >> wrote: > >> > >>> > >>> > >>> On 22 June 2013 23:31, James A. Donald wrote: > >>> > On 2013-06-23 6:47 AM, Peter Maxwell wrote: > > > > I think Bernstein's Salsa20 is faster and significantly more secure > than RC4, whether you'll be able to design hardware to run at > line-speed is > somewhat more questionable though (would be interested to know if it's > possible right enough). > > > I would be surprised if it is faster. > > > > >>> > >>> Given the 100Gbps spec, I can only presume it's hardware that's being > >>> talked about, which is well outwith my knowledge. We also don't know > >>> whether there is to be only one keystream allowed or not. > >>> > >>> However, just to give an idea of performance: from a cursory search on > >>> Google, once can seemingly find Salsa20/12 being implemented recently > >>> on > >>> GPU with performance around 43Gbps without memory transfer (2.7Gbps > >>> with) - > >>> http://link.springer.com/chapter/10.1007%2F978-3-642-38553-7_11 ) - > >>> unfortunately I don't have access to the paper. > >>> > >>> On a decent 64-bit processor, the full Salsa20/20 is coming in around > >>> 3-4cpb - http://bench.cr.yp.to/results-stream.html - and while cpb > >>> isn't > >>> a great measurement, it at least gives a feel for things. > >>> > >>> > >>> Going on a very naive approach, I would imagine the standard RC4 will > >>> suffer due to being byte-orientated and not particularly open to > >>> parallelism. Salsa20 operates on 32-bit words and from a cursory > >>> inspection of the spec seems to offer at least some options to do > >>> operations in parallel. > >>> > >>> If I were putting money on it, I suspect one could optimise at least > >>> Salsa20/12 to be faster than RC4 on modern platforms; whether this has > >>> been > >>> done is another story. Fairly sure Salsa20/8 was faster than RC4 > >>> out-of-the-box. > >>> > >>> As with anything though, I stand to be corrected. > >>> > >>> > >>> > >>> > >>> ___ > >>> cryptography mailing list > >>> cryptography@randombit.net > >>> http://lists.randombit.net/mailman/listinfo/cryptography > >>> > >>> > >> ___ > >> cryptography mailing list > >> cryptography@randombit.net > >> http://lists.randombit.net/mailman/listinfo/cryptography > >> > > > > > > ___ > > cryptography mailing list > > cryptography@randombit.net > > http://lists.randombit.net/mail
Re: [cryptography] 100 Gbps line rate encryption
Oops, miscalculation. That should be a 6.5 Ghz clock for 100 Gbps. ((100 Gbps/8)/2) . Anyway I don't think anybody has hardware that fast except maybe for IBM with the Power8. > The fastest hardware implementation of RC4 that I know is 2 bytes/clock. I > personally programmed a 1 byte/clock RC4 in a FPGA, it's quite simple. > > At 2 bytes/clock you still need a clock of 10 gigahertz to encrypt 100 > Gbps. That's unfeasible, the way it's done is using paralelism, then you > can use any algorithm you want as long as you have silicon available. > Consider there are 400 Gbps systems coming online. > > Using a PC for that kind of workload is a waste of money and power. FPGAs > are not that expensive nowadays. > > > > >> Just as a data point, on x86 processors with AESNI you can encrypt AES >> in, >> say, XTS mode with about 0.75 cycles / byte on each core. >> >> On an Intel Xeon E5-2690 'openssl speed -multi 4 -evp aes-128-xts' tops >> out >> at 13.5 GB/s for 8k blocks, which is 108 Gbps. That's only using half >> the >> physical cores and no hyperthreading. >> >> However, that's unlikely a realistic benchmark for whatever context the >> original question was referring to. >> >> >> On Sat, Jun 22, 2013 at 5:25 PM, Peter Maxwell >> wrote: >> >>> >>> >>> On 22 June 2013 23:31, James A. Donald wrote: >>> On 2013-06-23 6:47 AM, Peter Maxwell wrote: I think Bernstein's Salsa20 is faster and significantly more secure than RC4, whether you'll be able to design hardware to run at line-speed is somewhat more questionable though (would be interested to know if it's possible right enough). I would be surprised if it is faster. >>> >>> Given the 100Gbps spec, I can only presume it's hardware that's being >>> talked about, which is well outwith my knowledge. We also don't know >>> whether there is to be only one keystream allowed or not. >>> >>> However, just to give an idea of performance: from a cursory search on >>> Google, once can seemingly find Salsa20/12 being implemented recently >>> on >>> GPU with performance around 43Gbps without memory transfer (2.7Gbps >>> with) - >>> http://link.springer.com/chapter/10.1007%2F978-3-642-38553-7_11 ) - >>> unfortunately I don't have access to the paper. >>> >>> On a decent 64-bit processor, the full Salsa20/20 is coming in around >>> 3-4cpb - http://bench.cr.yp.to/results-stream.html - and while cpb >>> isn't >>> a great measurement, it at least gives a feel for things. >>> >>> >>> Going on a very naive approach, I would imagine the standard RC4 will >>> suffer due to being byte-orientated and not particularly open to >>> parallelism. Salsa20 operates on 32-bit words and from a cursory >>> inspection of the spec seems to offer at least some options to do >>> operations in parallel. >>> >>> If I were putting money on it, I suspect one could optimise at least >>> Salsa20/12 to be faster than RC4 on modern platforms; whether this has >>> been >>> done is another story. Fairly sure Salsa20/8 was faster than RC4 >>> out-of-the-box. >>> >>> As with anything though, I stand to be corrected. >>> >>> >>> >>> >>> ___ >>> cryptography mailing list >>> cryptography@randombit.net >>> http://lists.randombit.net/mailman/listinfo/cryptography >>> >>> >> ___ >> cryptography mailing list >> cryptography@randombit.net >> http://lists.randombit.net/mailman/listinfo/cryptography >> > > > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
The fastest hardware implementation of RC4 that I know is 2 bytes/clock. I personally programmed a 1 byte/clock RC4 in a FPGA, it's quite simple. At 2 bytes/clock you still need a clock of 10 gigahertz to encrypt 100 Gbps. That's unfeasible, the way it's done is using paralelism, then you can use any algorithm you want as long as you have silicon available. Consider there are 400 Gbps systems coming online. Using a PC for that kind of workload is a waste of money and power. FPGAs are not that expensive nowadays. > Just as a data point, on x86 processors with AESNI you can encrypt AES in, > say, XTS mode with about 0.75 cycles / byte on each core. > > On an Intel Xeon E5-2690 'openssl speed -multi 4 -evp aes-128-xts' tops > out > at 13.5 GB/s for 8k blocks, which is 108 Gbps. That's only using half the > physical cores and no hyperthreading. > > However, that's unlikely a realistic benchmark for whatever context the > original question was referring to. > > > On Sat, Jun 22, 2013 at 5:25 PM, Peter Maxwell > wrote: > >> >> >> On 22 June 2013 23:31, James A. Donald wrote: >> >>> On 2013-06-23 6:47 AM, Peter Maxwell wrote: >>> >>> >>> >>> I think Bernstein's Salsa20 is faster and significantly more secure >>> than RC4, whether you'll be able to design hardware to run at >>> line-speed is >>> somewhat more questionable though (would be interested to know if it's >>> possible right enough). >>> >>> >>> I would be surprised if it is faster. >>> >>> >>> >> >> Given the 100Gbps spec, I can only presume it's hardware that's being >> talked about, which is well outwith my knowledge. We also don't know >> whether there is to be only one keystream allowed or not. >> >> However, just to give an idea of performance: from a cursory search on >> Google, once can seemingly find Salsa20/12 being implemented recently on >> GPU with performance around 43Gbps without memory transfer (2.7Gbps >> with) - >> http://link.springer.com/chapter/10.1007%2F978-3-642-38553-7_11 ) - >> unfortunately I don't have access to the paper. >> >> On a decent 64-bit processor, the full Salsa20/20 is coming in around >> 3-4cpb - http://bench.cr.yp.to/results-stream.html - and while cpb isn't >> a great measurement, it at least gives a feel for things. >> >> >> Going on a very naive approach, I would imagine the standard RC4 will >> suffer due to being byte-orientated and not particularly open to >> parallelism. Salsa20 operates on 32-bit words and from a cursory >> inspection of the spec seems to offer at least some options to do >> operations in parallel. >> >> If I were putting money on it, I suspect one could optimise at least >> Salsa20/12 to be faster than RC4 on modern platforms; whether this has >> been >> done is another story. Fairly sure Salsa20/8 was faster than RC4 >> out-of-the-box. >> >> As with anything though, I stand to be corrected. >> >> >> >> >> ___ >> cryptography mailing list >> cryptography@randombit.net >> http://lists.randombit.net/mailman/listinfo/cryptography >> >> > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
Just as a data point, on x86 processors with AESNI you can encrypt AES in, say, XTS mode with about 0.75 cycles / byte on each core. On an Intel Xeon E5-2690 'openssl speed -multi 4 -evp aes-128-xts' tops out at 13.5 GB/s for 8k blocks, which is 108 Gbps. That's only using half the physical cores and no hyperthreading. However, that's unlikely a realistic benchmark for whatever context the original question was referring to. On Sat, Jun 22, 2013 at 5:25 PM, Peter Maxwell wrote: > > > On 22 June 2013 23:31, James A. Donald wrote: > >> On 2013-06-23 6:47 AM, Peter Maxwell wrote: >> >> >> >> I think Bernstein's Salsa20 is faster and significantly more secure >> than RC4, whether you'll be able to design hardware to run at line-speed is >> somewhat more questionable though (would be interested to know if it's >> possible right enough). >> >> >> I would be surprised if it is faster. >> >> >> > > Given the 100Gbps spec, I can only presume it's hardware that's being > talked about, which is well outwith my knowledge. We also don't know > whether there is to be only one keystream allowed or not. > > However, just to give an idea of performance: from a cursory search on > Google, once can seemingly find Salsa20/12 being implemented recently on > GPU with performance around 43Gbps without memory transfer (2.7Gbps with) - > http://link.springer.com/chapter/10.1007%2F978-3-642-38553-7_11 ) - > unfortunately I don't have access to the paper. > > On a decent 64-bit processor, the full Salsa20/20 is coming in around > 3-4cpb - http://bench.cr.yp.to/results-stream.html - and while cpb isn't > a great measurement, it at least gives a feel for things. > > > Going on a very naive approach, I would imagine the standard RC4 will > suffer due to being byte-orientated and not particularly open to > parallelism. Salsa20 operates on 32-bit words and from a cursory > inspection of the spec seems to offer at least some options to do > operations in parallel. > > If I were putting money on it, I suspect one could optimise at least > Salsa20/12 to be faster than RC4 on modern platforms; whether this has been > done is another story. Fairly sure Salsa20/8 was faster than RC4 > out-of-the-box. > > As with anything though, I stand to be corrected. > > > > > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
On Jun 22, 2013, at 15:31 , James A. Donald wrote: > On 2013-06-23 6:47 AM, Peter Maxwell wrote: >> >> >> I think Bernstein's Salsa20 is faster and significantly more secure than >> RC4, whether you'll be able to design hardware to run at line-speed is >> somewhat more questionable though (would be interested to know if it's >> possible right enough). > > I would be surprised if it is faster. Be surprised, then... almost all of the recent word- or block- oriented stream ciphers are faster than RC4. And NOTHING should still be using RC4; by today's standards it is quite insecure. Greg. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
On 22 June 2013 23:31, James A. Donald wrote: > On 2013-06-23 6:47 AM, Peter Maxwell wrote: > > > > I think Bernstein's Salsa20 is faster and significantly more secure than > RC4, whether you'll be able to design hardware to run at line-speed is > somewhat more questionable though (would be interested to know if it's > possible right enough). > > > I would be surprised if it is faster. > > > Given the 100Gbps spec, I can only presume it's hardware that's being talked about, which is well outwith my knowledge. We also don't know whether there is to be only one keystream allowed or not. However, just to give an idea of performance: from a cursory search on Google, once can seemingly find Salsa20/12 being implemented recently on GPU with performance around 43Gbps without memory transfer (2.7Gbps with) - http://link.springer.com/chapter/10.1007%2F978-3-642-38553-7_11 ) - unfortunately I don't have access to the paper. On a decent 64-bit processor, the full Salsa20/20 is coming in around 3-4cpb - http://bench.cr.yp.to/results-stream.html - and while cpb isn't a great measurement, it at least gives a feel for things. Going on a very naive approach, I would imagine the standard RC4 will suffer due to being byte-orientated and not particularly open to parallelism. Salsa20 operates on 32-bit words and from a cursory inspection of the spec seems to offer at least some options to do operations in parallel. If I were putting money on it, I suspect one could optimise at least Salsa20/12 to be faster than RC4 on modern platforms; whether this has been done is another story. Fairly sure Salsa20/8 was faster than RC4 out-of-the-box. As with anything though, I stand to be corrected. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
Would anybody dare to use a SHA256 based stream cipher? (XOR with checksum of key and counter or whatever you want to throw in there.) Would it be faster than RC4/Salsa20? I'm a bit curious about why nobody seems to be using hash/checksum based stream ciphers. 2013/6/23 James A. Donald > On 2013-06-23 6:47 AM, Peter Maxwell wrote: > > > > I think Bernstein's Salsa20 is faster and significantly more secure than > RC4, whether you'll be able to design hardware to run at line-speed is > somewhat more questionable though (would be interested to know if it's > possible right enough). > > > I would be surprised if it is faster. > > > > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
On 2013-06-23 6:47 AM, Peter Maxwell wrote: I think Bernstein's Salsa20 is faster and significantly more secure than RC4, whether you'll be able to design hardware to run at line-speed is somewhat more questionable though (would be interested to know if it's possible right enough). I would be surprised if it is faster. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
I think Bernstein's Salsa20 is faster and significantly more secure than RC4, whether you'll be able to design hardware to run at line-speed is somewhat more questionable though (would be interested to know if it's possible right enough). On 22 June 2013 18:35, William Allen Simpson < william.allen.simp...@gmail.com> wrote: > A quick question: what are our current options for 100 Gbps > line rate encryption? > > Are we still using variants of ARC4? > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
