[TODO] review digest-related code, offer stronger hashing algos with a prospect of eventually deprecating SHA1

[jnpkrn]

This is something that should be resolved in future, even more so when
following is considered:

• SHA1 being discouraged at this point
• fragility arising of two different hash implementation providers
  without strict signalling which one is in use (and hence which
  hash algo id to actual algo mapping is applicable)
• cross-node agreement on the algo

[dmuhamedagic]

Did you perhaps read the part of the README titled Authentication?

[jnpkrn]

On 10/05/16 10:37 -0700, Dejan Muhamedagic wrote:

Did you perhaps read the part of the README titled Authentication?

Yes, naturally.

I just anticipate a change that will be required in (perhaps distant)
future or due to requirements of various organizations, and for which
there's currently no support in the design so it will definitely won't
be a matter of just adding an extra knob. And this infrastructure,
even if no other digest algorithm is added for some time, is what will
ensure smooth transition once the call for such change is heard
(think: backward compatibility, at least at the message header level).

For instance, SHA-1 is currently approved for HMAC by NIST:

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf

but that will likely not last forever (MD5 is not recognized by FIPS
140, even it should not be significantly weaker in HMAC context).

---

Related to that, while booth-keygen does a good job (64 random-enough
bytes = 512 bits of entropy, even though 320 would be equally safe per
http://csrc.nist.gov/publications/nistpubs/800-107-rev1/sp800-107-rev1.pdf
in case of SHA-1), booth itself enforces only 64 bits of entropy within
the key, or merely ceil(log(52+10+30, 2) * 8) = 53 bits if standard
writeable passphrase is used instead.

This is in conflict with the RFC 2104 (sec. 3) recommendation (160 bits
as a minimum for SHA-1), and also against the limit in the mentioned
NIST document (112 bits as a minimum in general).

Shall we do something about that?

Jan (Poki)

[jnpkrn]

Also, I was made aware there are other (and more performant) keyed hash functions (UMAC, Poly1035, ...) so let's keep in mind the repertoire is far beyond selecting hash algo for HMAC.

[dmuhamedagic]

On Tue, May 10, 2016 at 12:44:07PM -0700, Jan Pokorný wrote:

On 10/05/16 10:37 -0700, Dejan Muhamedagic wrote:

Did you perhaps read the part of the README titled Authentication?

Yes, naturally.

I just anticipate a change that will be required in (perhaps distant)
future or due to requirements of various organizations, and for which
there's currently no support in the design so it will definitely won't
be a matter of just adding an extra knob. And this infrastructure,
even if no other digest algorithm is added for some time, is what will
ensure smooth transition once the call for such change is heard
(think: backward compatibility, at least at the message header level).

For instance, SHA-1 is currently approved for HMAC by NIST:

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf

but that will likely not last forever (MD5 is not recognized by FIPS
140, even it should not be significantly weaker in HMAC context).

---

Related to that, while booth-keygen does a good job (64 random-enough
bytes = 512 bits of entropy, even though 320 would be equally safe per
http://csrc.nist.gov/publications/nistpubs/800-107-rev1/sp800-107-rev1.pdf
in case of SHA-1), booth itself enforces only 64 bits of entropy within
the key, or merely ceil(log(52+10+30, 2) * 8) = 53 bits if standard
writeable passphrase is used instead.

This is in conflict with the RFC 2104 (sec. 3) recommendation (160 bits
as a minimum for SHA-1), and also against the limit in the mentioned
NIST document (112 bits as a minimum in general).

Shall we do something about that?

The user also has an option not to use authentication at all
which is then enforcing around 0 bits of entropy.

Is there a realistic chance of defeating SHA-1 and inserting
traffic such as a booth server would believe that it comes from
the server which has the shared secret?

Or are you talking about considering some future extension?

[jnpkrn]

On 12/05/16 09:58 -0700, Dejan Muhamedagic wrote:

The user also has an option not to use authentication at all
which is then enforcing around 0 bits of entropy.

Knowingly opting for no authentication at all is perfectly valid for
cases the internetwork is trusted and secured from outer factors.

Allowing deliberate weakening of the authentication strength by
not enforcing reasonable length (why is 8 characters at minimum
required, then?) of a shared secret (= misconfiguration avoidance)
is not, however; there's no middle ground, either you want
a security feature with some guarantees or you don't want it at all.

Is there a realistic chance of defeating SHA-1 and inserting
traffic such as a booth server would believe that it comes from
the server which has the shared secret?

I'm not saying SHA-1 is doomed in HMAC context, but there may be
people taking more-or-less rumours-based stance against this algorithm
(or dictated by directives from possibly similar-minded), and as
mentioned, there are other keyed MAC schemes with better
security/performance characteristics so why not eventually
offer something more optimal?

Or are you talking about considering some future extension?

And yes, this is a future prospect to allow alternatives, but that
requires some preparation work to allow that switching at all,
and that can be started early.

For instance, consider the clumsiness of allowing two implementations
of HMAC and mixing the algo identifier from two disjoint namespaces,
or that keygen would need to be taught about new, alternative
parameters.

Jan (Poki)

[jnpkrn]

Also BLAKE2 outperforms SHA-1 by more than 50% per the claims:
https://blake2.net/

[dmuhamedagic]

I doubt that there could ever be a security issue here, but perhaps this is worth considering for marketing purposes.