booth
booth copied to clipboard
ClusterLabs
[TODO] review digest-related code, offer stronger hashing algos with a prospect of eventually deprecating SHA1
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
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)
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.
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?
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)
Also BLAKE2 outperforms SHA-1 by more than 50% per the claims:
https://blake2.net/
I doubt that there could ever be a security issue here, but perhaps this is worth considering for marketing purposes.