[noise] Hybrid Forward Secrecy, version 1draft-2

[Rhys Weatherley]

On Tue, Sep 27, 2016 at 6:46 PM, Trevor Perrin <trevp at trevp.net> wrote:

> Cool, quick feedback:
>
>  * This currently mixes the "fg" notation with "dh??" notation, but
> the "fg" notation would be more consistent with changing from "dhee??"
> to "ee", "ss", "es", "se", so we need to think more about that.
>

Once (if?) the core specification changes, I will of course update the
extensions to match.

>
>  * If we change the existing notation so that "es" or "se" indicate
> the initiator's value by the first character, then it may make sense
> to allow "fg" and "gf" tokens that follow the same rule.
>
>  * It's awkward to use f and rf for the state variables that match
> both "f" and "g" tokens.  I would think there should be g and rg
> variables, so that this is handled consistently with s and e.
>

Both of these were less awkward when it was just "f" and "dhff". :-)

I've been working on the implementation for Noise-C (not pushed yet due to
a bug in my test vector generator).   Right now the code does this:

        case NOISE_TOKEN_F:
        case NOISE_TOKEN_G:
            if (token == NOISE_TOKEN_F)
                set-kex-object-into-alice-mode;
            else
                set-kex-object-into-bob-mode;
            ... rest of the code is the same for both ...
            break;

So I'm not sure anything is really gained by separating "f" into "f" and
"g".  The "alice mode" and "bob mode" flags can be intuited by a rule such
as "first f is alice, second f is bob".  Everything else is a problem for
the back-end implementation of the kex algorithm.

The public key value sizes may be different in New Hope, but the Noise-C
code doesn't actually care what the sizes are until after the alice/bob
mode is set.

This design may be a quirk of how I've implemented Noise-C though.  I'm
keen for someone else to try implementing New Hope in Noise to see what
other code shapes arise.

 * You mention allowing reuse of the hybrid ephemeral values.  This
> isn't covered by the pseudocode, which will generate a fresh value
> every handshake.  That's simpler and perhaps safer, since
> implementations don't have rotate keys via timer or other logic.  So
> could we get by without ephemeral reuse, for now?
>

I'm fine with that.  For New Hope, it is only the public "a" value that is
shareable - not the "key" part of the ephemeral key.  But New Hope "a"
generation is still pretty fast, so the value of reusing it is minimal.
Other algorithms might have different trade-offs.

Cheers,

Rhys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20160927/2c99a859/attachment.html>