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

Wed Jul 4 01:04:19 EDT 2018

On Mon, Jul 2, 2018 at 11:21 AM Jason Cooper <cryptography at lakedaemon.net>
wrote:

> Hi Alfie,
>
> On Sat, Jun 30, 2018 at 01:50:47PM +1000, Alfie John wrote:
> > On Mon, Jun 04, 2018 at 01:43:04PM +0000, Jason Cooper wrote:
> > > >
> > > > Non-deterministic-deterministic functions is an oxymoron... i know :)
> > > >
> > > > What I was trying to do was think of a way to get rid of the
> IV/nonce as
> > > > a parameter to an encrypt function call. I've seen code from many
> > > > organisation where the coder didn't know what to use for the IV
> > > > parameter, so they used the static values from examples copied from
> the
> > > > docs or even forum examples. Give a coder a footgun, and they'll use
> > > > it...
> > >
> > > Honestly, if the coder doesn't know to ask a cryptographer, or security
> > > engineer when they encounter nonce generation for an API, that's an
> > > education / experience problem.  A good manager should ensure the
> junior
> > > coder is either a) not going near crypto, or b) is closely supervised
> by
> > > an experienced crypto/security engineer when touching crypto.
> > >
> > > The best / easiest solution to your problem isn't technical,
> > > unfortunately.  It's human.  There's no substitute for experienced
> > > developers mentoring junior developers while working in crypto and
> > > security.
> >
> > I've been thinking about this for a while now...
>
> Good.  ;-)
>
> > My entire motivation for reducing parameters to calls was because the
> majority
> > of dev shops, let alone at-home hobby projects, do not have an in-house
> > security team. Even less likely an in-house cryptographer.
>
> Very true.
>
> > So this *really does* put cryptography out of reach for not only junior
> > developers, but also experienced developers who haven't done the required
> > reading to stay out of danger. This would probably be the main reason
> why there
> > is so much roll-your-own out in the wild and broken code.
>
> mmm.  That's a bit of a leap.  I'd say there's a lot of "roll-your-own"
> for two primary reasons: 1) hobbyists are tinkering and learning,
> hanging the result on github or whatever.  And 2) small shops have a
> need to secure product(s) and do it in a less-than-advisable manner.
>
> Nothing can be done about (1), other than avoid projects that don't have
> an active community, established security bug handling procedures, and
> multiple developers contributing / maintaining code.
>
> (2) seems to occur for two main reasons.  The first is cost / speed.  An
> established product suddenly needs to "add security", the cheapest /
> fastest way to do so is to have the existing dev team do it.  And that
> wasn't what they were hired for or experienced in.  The second reason
> unfortunately seems to be arrogance.
>
> There's also a third, which is just flat-out mistakes.  The PS3 DSA
> nonce is a good example of that (I've never met the engineers who made
> the mistake, so I'll presume mistake over arrogance ;-) ).
>
> > libsodium does an awesome job to reduce mistakes and encourage best
> practices,
> > but I think we can reduce the mental load even just a little bit more
> e.g by
> > generating the nonce inside of crypto_aead_chacha20poly1305_encrypt()
> and then
> > appending it to the ciphertext (just like it already does to the
> authentication
> > tag). The first thing crypto_aead_chacha20poly1305_decrypt() would do is
> strip
> > the nonce off the end and use it as it does now.
>
> Well, sure.  But that's a protocol design decision.  Do you really want
> the developer who needs to have their hand held regarding nonce
> generation to be designing cryptographic protocols?
>
> Regarding your example, it's much better if the nonce is pre-pended.
> This way, you can do an early check for duplicated messages (use the
> nonce as a unique message ID) and drop it before even trying to
> decrypt/auth it if you already received it.  This is especially helpful
> when an encrypted message spans multiple MTUs.
>
> > (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>

> >
> > Going to be hard for a non-expert to use the above code incorrectly.
>
> Yeah, that's the problem with interface abstraction.  Just because it
> looks nice doesn't mean it's genuinely useful or helpful.

I found that Tink's interfaces are useful for a large number of use cases.

This
> interface sucks because you've made a decision for me regarding
> placement of the nonce in the message.

You're probably not the target audience for this API.

> 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.

My employer has 20-30K developers. Only 10-20 persons are allowed to roll
own crypto including my team. The rest use our interfaces. I cannot remember
the last time someone complained that they cannot use the interfaces because
they needed to choose their own nonces.

> The unfortunate side effect of an api like the above is that a junior
> developer is then never exposed to nonce handling, but now thinks they
> know how to design cryptographic protocols.  That's dangerous.

A competent security program should never require developers to know
anything
about nonces, let alone designing crypto protocols. These jobs are best
left to
the professionals.

A better solution (not applicable here, but same class of problem) is
> Apple's recently announced Network.framework [1].  We can debate the
> efficacy of the userspace network stack, but it puts the abstraction
> right where it should be, at a very high level.  The developer is under
> *no* pretense that they are "designing" or "implementing" TLS, bonjour,
> DTLS, etc.  They are merely *using* those protocols.
>
> And that helps us see where libsodium and friends (openssl, mbedTLS,
> etc) fit in.  They are convenience libraries for _protocol
> implementers_, not junior developers.
>
>
> hth,
>
> Jason.
>
> [1] Video: https://developer.apple.com/wwdc18/715
>     Slides:
> https://devstreaming-cdn.apple.com/videos/wwdc/2018/715o2fzpdzzzf5f0/715/715_introducing_networkframework_a_modern_alternative_to_sockets.pdf
>     Example (C):
> https://developer.apple.com/documentation/network/implementing_netcat_with_network_framework
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography

-- 
https://vnhacker.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180703/42762eb4/attachment.html>