[Cryptography] encryption + authentication - waiting - chaining

[iang]

Hi John,


On 23/03/2017 18:06, John Denker via cryptography wrote:
> As for making things resistant to misuse: I am reminded of the following:
>   ++ For every proverb, there is an equal and opposite proverb.
>
> In this case, there is a proverb that says we should make it easy to
> do the right thing, and hard to do the wrong thing.  However, there is
> another proverb that says garbage in, garbage out.
>
> For example, an ordinary lawnmower comes with a number of safety features.
> Even so, it remains open to abuse in innumerable ways, and even if used
> carefully there is some irreducible risk.  (Not to mention the urban legends
> about the dangers of picking up a lawnmower and using it to trim hedges.)
>
> There is a nontrivial issue here.  It is *much* more nuanced than saying:
>   -- "it's unsafe to use a stream cipher",
>   -- "it's safe to use AES, because only an idiot would use related keys", or
>   -- "use XXX because it retains some modicum of security even if the IV is reused".
>
> Instead I would say:
>   ++ Sometimes there are good reasons for a stream cipher, but you have
>    to be careful.
>   ++ Sometimes there are good reasons for using a bunch of related keys,
>    but you have to be careful.
>   ++ Sometimes it's safe to use AES, but you have to be careful.
>   ++ Sometimes it's OK to mow the lawn, but you have to be careful.
>   ++ You can't make anything foolproof, because fools are so ingenious.

I'd rather just say - most every protocol is a datagram protocol at its 
heart, and as most every datagram is of uncertain length, a stream 
protocol is far better.  If you haven't got a sponge function to hand 
(hint, hint) then a stream cipher is probably the next best thing to use 
(e.g., chacha/poly).  If not, you're going to have to look for an AEAD 
algorithm, most of whom are a kludge to turn a block cipher into a 
stream cipher.  Worst option is, you're going to have to build a stream 
cipher yourself out of block ciphers and modes.  There be dragons.  Good 
luck!

Which is to say, I'd rather tackle the issue head-on:  The block ciphers 
may be great but they are the wrong tool.  The stream ciphers may be 
crap, but they are the right tool.  For extra points, a sponge function 
is the better way.

> On 03/18/2017 03:58 AM, Jerry Leichter wrote:
>
>>> We don't know how to compose secure modules into larger systems and maintain their security.
> Indeed!
>
> One can fantasize about a formal language that would specify what each
> module requires and what it provides (in loose analogy to a package
> management system like dpkg).
>
> Right now I would settle for an informal language, perhaps a checklist.
> For example, a certain mode:
>   -- requires an IV that is unguessable
>   -- requires a generic block cipher
>       (which will bring in its own requirements)
>   -- requires absence of transmission dropouts
>       (this is because of chaining)
>   -- provides message encryption
>   -- does not provide authentication
>   -- does not provide random access
>   -- does not provide real-time service
>   -- does not provide protection against traffic analysis

Hmm.  There is another approach.  The unrealised innovation in djb's 
*code* for chacha/poly is something I also do:  a tight vertical stack 
that does the entire thing required and only the thing.  Throw out the 
library and build the cryptobox as the complete thing.  The construction 
requires top to bottom coding adroiticity or some aggressive cut&paste.

iang