Hey,
In libotr4.0/protocol v3 we won't be changing anything that is SHA-1.
This is mostly because we are trying to get libotr4.0 out the door (I
am aiming to get a beta into sourceforge git tonight!).
For the next version, we will definitely be re-examining things that
use SHA-1.
Regards,
Rob Smits
Quoting Paul Wouters <[email protected]>:
Hi,
A cursory glance at the libotr code shows it is performing SHA1
operations. Looking at the protocol v2 spec, it seems that SHA1 is
hardcoded. Does the imminent updated specification allow for different
pluggable hash algorithms, or at least bump the hash algorithm to to SHA256?
Similarly, the pidgin-otr code seems to use SHA1 to store public keys
as finger prints. I assume that can easilly be changed to SHA25 without
interop issues, as I assume this is only a local representation?
The reason for this is two-fold. One is that SHA1 will soon no longer
be allowed in FIPS mode, and I would like OTR to still fall within the
security of a FIPS mode machine. Second, I'm looking at storing the OTR
long term public key hashes in DNS (signed with DNSSEC) and would prefer
to use SHA256 as the minimum hash algorithm.
Note that FIPS does not discriminate between any kind of operation, so
it treats algorithms used for long term encryption (20 years) the same
as algorithms used for short term signatures (eg 3 days for DNSSEC). It
does this to make compliance easier for implementors and auditors. It
does not always make much sense, such as in the case of HMAC. And it
might not make sense in the context of OTR with its current size of
random numbers and AES keysizes.
Paul
_______________________________________________
OTR-dev mailing list
[email protected]
http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
_______________________________________________
OTR-dev mailing list
[email protected]
http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
