[OTR-dev] OTR and SHA1

[Rob Smits]

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 <paul at cypherpunks.ca>:

>
> 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
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
>
>