7
$\begingroup$

CTR mode does not use the decryption function at all, only the encryption function.

This may suggest that a different primitive that has this "one-way" property could do the trick. For instance, I just thought we could map the secret key with the counter under a secure hash function to obtain a complete usable and secure cipher with CTR mode, why is this assertion false?

Maybe a secure hash is not enough, but

Can we use a different primitive as a cipher in CTR mode, not necessarily a PK Cryptosystem?

Thanks a lot for your answers and comments.

$\endgroup$
  • 2
    $\begingroup$ Can I ask the relevance of the public-key tag? There's no mention of public/private key anything in your question. There are plenty of questions here that ask about turning a hash function into a stream cipher. tl;dr, You can get a random oracle proof, but hash functions aren't random oracles, and nobody will promise you that it's a good idea that will work as expected in the real world/Just stick to using primitives for what they were designed+vetted for. $\endgroup$ – Ella Rose Jul 8 '16 at 2:08
  • $\begingroup$ @EllaRose Thanks for the comment. Indeed, there was a problem with the tag, that I've already fixed. I'll take a look to those questions. $\endgroup$ – Daniel Jul 8 '16 at 2:34
  • $\begingroup$ See also: crypto.stackexchange.com/questions/35110/… $\endgroup$ – otus Jul 8 '16 at 8:59
  • $\begingroup$ I am using it this way myself. I use AES256CTR to encrypt large inputs with random keys. I use a large master password to "CTR ENCRYPT" these passwords with SHA256CTR. It is stored as (sha256(master,IV) xor fileKey). Which is like CTR using SHA that is only one block long. The advantage is that (master) can be 60 chars of stepping on the keyboard, or just the name of your dog. Users don't circumvent this, and use memorable passwords if they have to. $\endgroup$ – Rob Jul 8 '16 at 20:54
11
$\begingroup$

Your intuition is on the right track: if you run a pseudorandom function in counter mode with your secret key, you get a stream cipher. Some stream ciphers are designed like this, perhaps most notably Salsa20 (and its later variant ChaCha20).

But the key to answering your question, as I see it, is to note that a collision-resistant hash function like SHA-2 is more complicated than what you need for this use:

  1. You don't need the collision resistance property of cryptographic hash functions.
  2. Standard cryptographic hash functions are unkeyed; they don't take a secret key as input. You are using a custom construction to incorporate a secret key into your use of a hash function, and that means that you have to ask if your construction is secure, or use a standard construction that has been analyzed to be secure.
  3. Hash functions (as normally understood) feature compression—they turn input data of arbitrary length into a fixed output size. But you're feeding fixed-size inputs to the hash function.

So what you really want is a pseudorandom function that takes these three fixed-size arguments:

  1. The key (secret);
  2. A nonce (not secret);
  3. A block counter value (not secret);

...and produces a fixed-size keystream block. So if you read for example RFC 7539 ("ChaCha20 and Poly1305 for IETF Protocols") you'll notice that this is precisely the interface of the ChaCha20 block function (section 2.3):

2.3. The ChaCha20 Block Function

The ChaCha block function transforms a ChaCha state by running multiple quarter rounds.

The inputs to ChaCha20 are:

  • A 256-bit key, treated as a concatenation of eight 32-bit little-endian integers.
  • A 96-bit nonce, treated as a concatenation of three 32-bit little-endian integers.
  • A 32-bit block count parameter, treated as a 32-bit little-endian integer.

The output is 64 random-looking bytes.

Or, alternatively, feed the exact same inputs to a block cipher like AES. Block ciphers are pseudorandom permutations (a subset of pseudorandom functions) and thus already keyed, and they work on fixed-size inputs already (they don't feature compression), so they're a good tool for this use.

$\endgroup$
  • $\begingroup$ Oh I see... my intuition was like "why using an encryption scheme if we could use a (simpler?) secure hash function?" but indeed, this may not e simpler at all! thanks a lot for the answer and the examples. $\endgroup$ – Daniel Jul 8 '16 at 22:40

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