There are current state-of-the-art encryption algorithms, which considered absolutely safe currently, like AES. Their speed is around the 100MB/sec ballpark on current PCs (note: this is the speed when AES instruction set is not used - I'm interested in the general case, not when HW acceleration is available).

And there are fast, non-safe, obfuscation-only algorithms, like for example, xoring with some fast general-purpose, non-cryptographic random. Their speed can be very-very fast, possibly in the 10GB/sec range. But they can be broken easily (if a little part of the clear-text is known, they can be broken immediately).

Are there any algorithms, which are between these? Like, it has speed of ~1GB/sec, and it can be broken, with some computational effort (like the key can be found in a week/month/year of bruteforce searching on a current PC)?

It can be used in a scenario, when speed matters, but the data is not that sensitive, so it would not worth to break the encryption.

  • 2
    $\begingroup$ Maybe I am wrong, but 100MB/sec sounds low for a current AES-NI enabled CPU. $\endgroup$ – Guut Boy Nov 8 '17 at 12:16
  • 9
    $\begingroup$ According to the Crypto++ benchmarks, AES is more in the 4GB/s ballpark than in the 100MB/s one. On my laptop, which is just a normal laptop with AES-NI instructions, running openssl speed -elapsed -evp aes-128-ccm is giving me values in the range of 300+GB/s (and it seems to be using just one core). $\endgroup$ – Lery Nov 8 '17 at 12:19
  • 2
    $\begingroup$ @GuutBoy: sure. But if AES-NI is not available, it is ~100MB/sec. But that's not the point here, it was just an example. All safe encryption algorithms (known by me) is around X*100MB/sec (where X is a small number). This question is not about which is the fastest possible AES implementation, but is there an algorithm, which is faster than the safe ones, while has less safety guarantees. $\endgroup$ – geza Nov 8 '17 at 12:23
  • $\begingroup$ @geza maybe you should rephrase the question then. As it stands now it sound like you are looking for a cipher in the ~1GB/s range. $\endgroup$ – Guut Boy Nov 8 '17 at 12:37
  • $\begingroup$ @Lery: that number seems pretty weird. For my machine, I got 600GB/sec, which means that each cycle, it processes 146 bytes. It seems impossible... ccm is 600GB/sec, while cbc is 940MB/sec. There is a 640x difference between them. But, as I've said to Guut Boy, that's not the point here. (I've edited my question a little bit, to make this clear). $\endgroup$ – geza Nov 8 '17 at 12:55

A classical table-based AES implementation would achieve about 160 MB/s on my current computer (a fairly recent MacBook Pro). However, one can do better; of course there are the AES-NI instructions, that easily bump up speed on that machine to the 5 GB/s mark (with a parallel mode such as AES-CTR; AES-CBC encryption is much slower). But even without these instructions, the Käsper-Schwabe implementation of AES-CTR would offer more than 400 MB/s, a substantial improvement.

Looking outside of AES, there is ChaCha20, as specified in RFC 7539. Using my own implementations, the purely generic, 32-bit plain C code (chacha20_ct) encrypts or decrypts data at 385 MB/s on my laptop; the SSE2-enhanced implementation (chacha20_sse2) offers a 584 MB/s.

Generally speaking, block ciphers like AES are versatile primitives, and it can be argued that, by forfeiting versatility and concentrating on the encryption/decryption role, better performance may be achieved. This is what stream ciphers like ChaCha20 are about.

About ten years ago, there was the eSTREAM project which resulted in a portfolio of stream ciphers. On my laptop, SOSEMANUK achieves about 1.64 GB/s, which is not bad for a design from ten years ago. Notably, it is 10 times faster than the table-based AES. (I wrote part of the code; I don't know who packaged it as a Zip archive with modified file names that break compilation.)

Among more modern designs, one may cite NORX. I encountered an implementation on small ARM systems that was consistently trouncing ChaCha20. I suppose it would also clear the 1 GB/s mark on a modern PC.

Summary: 1 GB/s is actually highly feasible with existing algorithms, on standard hardware, without using the AES instructions, and without sacrificing security: all of the above are currently unbroken, despite extensive exposure to vindictive cryptographers.

Of course, excluding the AES-NI instructions is rather artificial: it makes relatively little sense to make benchmarks on a modern CPU without using the features of that CPU. Performance on smaller, embedded systems without an hardware AES implementation may be more relevant.

| improve this answer | |
  • 1
    $\begingroup$ Thanks for the answer! SOSEMANUK seems very viable. I excluded AES-NI because I cannot depend on it. I need a cross-platform solution, which performs equally well on all platforms (I need to use the same algorithm on all platforms). $\endgroup$ – geza Nov 8 '17 at 14:08
  • $\begingroup$ Thomas, does your answer mean, that no "not totally secure but hard enough to be safe" ciphers developed? So researchers only develop ciphers which aim complete safety? $\endgroup$ – geza Nov 8 '17 at 16:09
  • 1
    $\begingroup$ @geza Yes, that's about it. In fact, there is no obvious way to make a cipher that is not immediately breakable, and yet faster than a safe one. Thus we simply aim at really secure algorithms. $\endgroup$ – Thomas Pornin Nov 8 '17 at 16:30
  • 3
    $\begingroup$ “performs equally well on all platforms” cannot be possible, as all platforms do not perform equally to start with $\endgroup$ – OrangeDog Nov 8 '17 at 16:38
  • $\begingroup$ @OrangeDog: I meant that compared to a non-HW-accelerated cipher, not that the performance should be the same on all platforms. HW-accelerated AES is not an option, because it has good performance only on platforms where the acceleration is available. But, for example, SOSEMANUK should be faster on all platforms compared to a non-HW-accelerated AES. $\endgroup$ – geza Nov 8 '17 at 16:44

There are some lightweight stream ciphers that might be 10x faster than some implementations of AES. Achterbahn is apparently 1 cycle per byte, Salsa20 might be as low as 4, compared to AES which might be 18.

In theory you could make something secure as fast as your lower bound (just XOR with a CSPRNG that you have created earlier).

| improve this answer | |
  • $\begingroup$ Thanks for the answer, quite useful, now I'm checking out the various ciphers. Where did you find the information that Achterbahn is 1 cycle/byte? Btw, I found this: ecrypt.eu.org/stream/ciphers/abc/abc.pdf. The authors claim that it can do 850MB/sec on a pentium 4, so with current CPUs, this can be even more faster. $\endgroup$ – geza Nov 8 '17 at 13:35
  • $\begingroup$ en.wikipedia.org/wiki/… for the 1 cpb claim. \ $\endgroup$ – daniel Nov 8 '17 at 14:42
  • $\begingroup$ What hardware are those cycle counts on? The paper you linked only mentions CPB for AES on 8-bit RISC AVR microcontrollers, which is obviously going to be very different from a 32-bit ARM, or a superscaler / out-of-order x86-64 (even without using AES-NI). $\endgroup$ – Peter Cordes Nov 9 '17 at 3:31
  • $\begingroup$ @PeterCordes I don't know it's just from the Wikipedia table $\endgroup$ – daniel Nov 9 '17 at 8:08
  • $\begingroup$ Most of the CPB entries have a note that links to Pentium 4, Pentium III, ARMv7TDMI, or whatever. Achterbahn just says "hardware", so presumably they're talking about an FPGA or ASIC implementation. Hardly surprising that makes it very fast... $\endgroup$ – Peter Cordes Nov 9 '17 at 14:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.