3
$\begingroup$

I came across a Chrome extension: Minilock

It's blog contains a post: "No, the NSA Isn't Breaking AES". Small excerpt is below:

A block cipher key is pretty much an initial seed for a pseudo-randomness permutation more than anything, and that’s why newer ciphers have focused on adding features (such as AEAD) instead of making ciphers “harder to break”. The most likely source of design weaknesses in block ciphers are likely to be not in the block cipher itself, but in its mode of operation (ECB spot-the-penguin, CBC bit-flipping, CTR nonce-reuse, to name a few). This is why block ciphers are now discouraged, and most new ciphers are moving to the stream cipher model.

Recently few ransomware started using stream ciphers like Salsa20 (probably because of speed).

I want to know whether there is more chance of implementation flaw in block ciphers as compared to stream ciphers like Salsa20?

If we are not confident with AES implementation, a stream cipher should be used?

$\endgroup$
  • $\begingroup$ The author is right about the facts: Wrong usage of modes of operation are a possible weaknesses. But the conclusion to use stream ciphers instead is just conjecture. I am not sure how you got to think of implementation erors then, but: That can happen for any crypto algorithm, and it's not unlikely. But it's another possible weakness. And another possible weakness are sidechannels, which also can be applicable for any crypto implementation. That all of these things have been looked into for AES, but that doesn't mean others don't have that problem. Just that no one looked into it so far. $\endgroup$ – tylo Oct 14 '16 at 9:30
  • 2
    $\begingroup$ @axapaxa Salsa20 is fast. ChaCha20 has a few minor speed improvements due to the changed rotation constants, but the difference is not major. Salsa20 is still an extremely lightweight stream cipher. $\endgroup$ – forest Feb 2 at 7:22
  • $\begingroup$ @forest you are right, Chacha20 is basically same except better rotation constants (which is useful change, but not huge). Removed that comment as to not confuse people. Fact remains that Chacha20 is as fast or faster on most platforms. $\endgroup$ – axapaxa Feb 10 at 13:32
7
$\begingroup$

A block cipher is a very versatile building blocks for implementing various cryptographic algorithms, such as hash functions, message authentication codes, and yes, also stream ciphers. You almost never use a block cipher on its own, but as part of some higher level construction. In a way, a block cipher is a bit like the engine in a car — it needs the rest of the car (or truck or boat or airplane) around it to actually do anything useful.

A stream cipher, on the other hand, does just one thing: it encrypts a stream of data. (Some modern ones may also authenticate the data being encrypted, to protect it from tampering.) While you can build a stream cipher by using a block cipher in an appropriate way, a purpose-built stream cipher has "no user-serviceable parts inside" — it's a bit as if a car had the engine and the frame permanently fused together, so that you couldn't separate them without tearing the whole car to pieces.


Now, the article does have a point is saying that the main source of vulnerabilities in block cipher based encryption schemes is not the block cipher itself, but the way it is used. To stretch the car analogy even further, cars don't usually fail because the engine blows up — more likely they fail because there's something wrong with the drivetrain or the steering or the electrics or the suspension, or because the driver was distracted and ran into an obstacle.

Also, because there are so many different ways to use a block cipher for different purposes, it's arguably easy for a non-cryptographer to select the wrong way of using it. In particular, to anyone who knows a bit of cryptography, saying that something is "encrypted using AES" is an immediate red flag, because it doesn't say anything about how AES is being used.

For all we know, you could be using AES-ECB (bad idea) or AES-CTR with a fixed nonce (really bad idea) or AES-CBC with a predictable IV (bad idea if the attacker can submit chosen plaintexts to be encrypted) or with padding oracle vulnerabilities (hard to avoid with CBC, and a bad idea unless you use a message authentication layer on top). Or you could be using AES-SIV (an excellent choice for a maximally foolproof design) or AES-GCM (a pretty good choice for raw speed, and secure as long as your nonces are unique) or even AES-GCM-SIV (a fairly new mode that combines the speed of GCM with the foolproofness of SIV).

Besides, the fact that you're using AES really isn't that relevant for cryptographic security — block ciphers are, by design, interchangeable, and any other unbroken block cipher with comparable block and key sizes is basically a valid drop-in replacement for AES. What really matters is whether you're using the block cipher in a manner that's appropriate for the purpose (e.g. any IND-CCA2 secure authenticated encryption mode for ordinary message encryption, an appropriate disk encryption mode for mutable random access data, etc.)


All that said, simply using a stream cipher doesn't magically make your code secure, either. Sure, with fewer choices, there are fewer ways to make wrong choices — but "fewer" doesn't mean "none at all", and worse, one of the possible wrong choices you can make with stream ciphers is choosing the wrong stream cipher in the first place, or not realizing that you may need something more than just the stream cipher.

In particular, most traditional stream ciphers (including e.g. DJB's Salsa20 and ChaCha ciphers, if used without a MAC) are vulnerable by design to exactly the same bit-flipping and nonce reuse attacks as block ciphers in CTR or OFB mode are. To protect against those attacks, you need an authentication layer on top of the cipher, and a secure way of generating unique nonce values.

So I would say that the conclusion ("block ciphers are now discouraged") is wrong. Block ciphers are here to stay, and there's no way that stream ciphers could ever displace them, because there are lots of things block ciphers can be used for that stream ciphers cannot.

What is (or at least should be) discouraged, however, is handing out isolated low-level components like AES or Salsa20 to developers, and expecting them to build a secure cryptosystem on top of them. What you should do instead, as far as possible, is use a standardized authenticated encryption scheme that already contains all the necessary components, and specifies how they should fit together, and which has been published and independently reviewed by multiple crypto experts. Preferably you should also be using a pre-existing implementation of the complete system that has been written by a competent cryptographer and published and reviewed for possible implementation flaws and side channel leaks.

Whether the chosen system is based on just a block cipher (like AES-SIV) or on a block cipher and a separate MAC (like AES-GCM or Poly1305-AES) or on a stream cipher and a MAC (like Salsa20-Poly1305) is, at that point, of much lesser importance. In fact, I would argue that it is completely irrelevant, except insofar as it affects the speed, resource use and external security constraints (e.g. whether the system needs a secure source of randomness, and whether it is safe to use on hardware that might be tampered with by an attacker) of the chosen system.


Ps. As for the recent popularization of stream cipher based encryption schemes, I would argue that it's as much a fashion swing as anything else.

At the moment, after a relatively long period where most crypto research focused on block ciphers, we just happen to have a bunch of novel stream cipher designs that are new and sexy (there haven't really been any prominent new block ciphers since AES established its position). Several of these ciphers, like Salsa20 and ChaCha, have been designed and promoted by a well known and trusted crypto researcher (D.J. Bernstein) who also happens to be the author of a popular crypto library (NaCl) and notably skilled at writing fast and secure low level crypto code, which also just happens to mean that they come with standard implementations that run blazingly fast on popular CPUs (which is attractive to companies like Google that transmit a lot of encrypted data over HTTPS).

This also coincided with the discovery of generic attacks against several widely used block cipher based cipher suites in the SSL/TLS protocol, which made it important to find new alternatives for them. As such, it's hardly a surprise that stream cipher based encryption schemes just happen to be in vogue right now.

$\endgroup$
  • $\begingroup$ Competent cryptographers rarely build a complete system. I think they just design algorithms or may be consulted if it is a commercial application. $\endgroup$ – RPK Oct 14 '16 at 12:21
  • $\begingroup$ @RPK: ...and that is a problem, because the person who puts the parts together still needs to have a pretty good understanding of how to do it securely. $\endgroup$ – Ilmari Karonen Oct 14 '16 at 12:36
3
$\begingroup$

This is why block ciphers are now discouraged .. most new ciphers are moving to the stream cipher model

I woudn't claim that. From this point - I'd disagree with the author of the blog. So far I am not aware of any reason to discourage the block ciphers, mainly when they have pretty amount of the analysis behind.

The author mentioned incorrect use of the mode of the operation.

I want to know whether there is more chance of implementation flaw in block ciphers as compared to stream ciphers like Salsa20?

I'd say - the chances are comparable. In the cryptography it's easy to shoot yourself into your own leg. It really depends on the implementation.

If we are not confident with AES implementation, a stream cipher should be used?

The idea is - there are different use of the stream and block ciphers. It woudn't be very efficient to use a stream cipher to encrypt a disk and then trying to read/modify only a portion of it.

On the other side - it's easy (and common) to use a block cipher as a stream using the CRT or OFB mode.

Edit:

The Salsa stream cipher is as well effectively a block cipher with a CRT mode ( mapping a key, a nonce, and a stream position (counter) to a 512-bit block of the key stream)

$\endgroup$
  • $\begingroup$ For an ordinary user like me, how to determine any tool is secure if implementation is correct? $\endgroup$ – RPK Oct 14 '16 at 10:09
  • 1
    $\begingroup$ @RPK: A rule of thumb - use common protocols, common tools, common frameworks if possible. They may be not perfect, but at least they are reviewed/fixed and time-proven. I woudn't trust anything custom-built or hidden. Unfortunatelly - we can never be sure (see history of the SSL protocol or OpenSSL tool), some weaknesses are found only after many years. $\endgroup$ – gusto2 Oct 14 '16 at 13:32
  • $\begingroup$ For file encryption, which tools you recommend? $\endgroup$ – RPK Oct 14 '16 at 18:37
  • $\begingroup$ Do you want to encrypt individual files or whole (virtual) disk? Which OS do you need it for? $\endgroup$ – gusto2 Oct 16 '16 at 16:52
  • $\begingroup$ Individual files. Windows 7 $\endgroup$ – RPK Oct 27 '16 at 13:56

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.