[Cryptography] Non-deterministic PRF as a MAC-and-Nonce for AEAD?

Alfie John alfie at alfie.wtf
Sat Sep 1 06:44:02 EDT 2018

Hey Thai,

On Tue, Jul 03, 2018 at 10:04:19PM -0700, ⛷ Thai Duong wrote:
> > > (another cleanup would be to remove alltogether the nsec parameter...)
> > >
> > > Once you did this, look at the clean interface you have, especially in a
> > > language that understands string lengths:
> > >
> > >     my $ciphertext                  =
> > crypto_aead_chacha20poly1305_encrypt($message, $additional_data, $key);
> > >     my ($message, $additional_data) =
> > crypto_aead_chacha20poly1305_decrypt($ciphertext, $key);
> >
> <shameless plug>
> Have you checked out Tink? We provide misuse-proof APIs like your proposal.
> Quoting our security and usability design goals [1]:
> Tink assumes that the attacker has complete freedom in calling methods of a
> high level interface; under this assumption the security is not
> compromised. For example, if the underlying encryption mode requires nonces
> and is insecure if nonces are reused then the interface does not allow to
> pass nonces. Tink also assumes that the attacker can get access to memory
> passed into a method, even if a crypto operation (e.g. decryption) failed.
> [1] https://github.com/google/tink/blob/master/docs/SECURITY-USABILITY.md
> </shameless plug>

I just saw this on my timeline and made me realise I totally forgot to reply to
your message. Apologies, and congratulations on the public release. I'll be
checking it out.

> > It also sucks for your target
> > audience because they still have to design a good protocol *with* the
> > bad placement of the nonce.
> I found that it's good for all software developers, regardless of their
> seniority.

This is what I was originally hoping for. Glad to see this in Tink. I believe
it's the way forward - making cryptography safer to use in the hands of
non-experts. Awesome work!


Alfie John

More information about the cryptography mailing list