Raw bytes from randomness source should be hashed before usage in keys (#135) · Issues · Libraries / libotr

Raw bytes from randomness source should be hashed before usage in keys

My friend Jakob Bleier, a Master's student at Raboud Universiteit, discovered that libotr uses raw bytes directly from its source of randomness (some garbled libgcrypt function) for the DH signing key, which is ultimately revealed in the Reveal Signature Message upon session completion. This is arguably not a bug, however, Jakob argues (and I would agree with him) that the OTR protocol should be specified and implemented in a way which does not leave ambiguities allowing implementers to shoot themselves and users in the foot. The idea is that, for example, on a system where the RNG is backdoored, or whatever library is used to retrieve randomness (e.g. libcrypt, or javac/bouncycastle in the case of otr4j) giving away the state of the RNG could allow an attacker to derive state at another point in time, compromising keys which may still be in use. Implementers shouldn't need to be familiar with the intricacies of the RNG in order to implement OTR safely.

The fix is quite simple, obviously, just hash the randomness before using it. (Tor does this as well.)

Jakob expressed interest in submitting a patch… I'll poke him and his advisors (Ruben Niederhagen and Peter Schwabe) and point them at this ticket.

(from redmine: created on 2016-03-01)

My friend Jakob Bleier, a Master's student at Raboud Universiteit, discovered that libotr uses raw bytes directly from its source of randomness (some garbled libgcrypt function) for the DH signing key, which is ultimately revealed in the Reveal Signature Message upon session completion. This is arguably not a bug, however, Jakob argues (and I would agree with him) that the OTR protocol should be specified and implemented in a way which does not leave ambiguities allowing implementers to shoot themselves and users in the foot. The idea is that, for example, on a system where the RNG is backdoored, or whatever library is used to retrieve randomness (e.g. libcrypt, or javac/bouncycastle in the case of otr4j) giving away the state of the RNG could allow an attacker to derive state at another point in time, compromising keys which may still be in use.  Implementers shouldn't need to be familiar with the intricacies of the RNG in order to implement OTR safely.

The fix is quite simple, obviously, just hash the randomness before using it. (Tor does this as well.)

Jakob expressed interest in submitting a patch… I'll poke him and his advisors (Ruben Niederhagen and Peter Schwabe) and point them at this ticket.

*(from redmine: created on 2016-03-01)*

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information