[OTR-users] [OTR-dev] otr dh key encryption

[Ileana]

On Tue, 19 Feb 2013 20:35:09 +0100
Kjell Braden <kb at pentabarf.de> wrote:

> On 2013-02-19 19:58, Ileana wrote:
> > On Tue, 19 Feb 2013 11:36:36 +0100
> > Kjell Braden <kb at pentabarf.de> wrote:
> >
> >>
> >>    Also, you confuse two different concepts of authentication:
> >>    Every OTR session uses cryptographic authentication. If you
> >> previously marked a key as trusted (ie. you know it belongs to the
> >> reported owner), OTR will flag it as trusted again if you come back
> >> later to the same DSA key.
> >
> > Another note on this:  doesn't this destroy your "plausible
> > deniability"?  If there is some DSA key stored on my computer, that
> > I keep showing to everyone I chat with, and is recoverable if my
> > computer is seized...what is deniable about that?
> 
>   You might want to read the OTR protocol spec [1].
> 
>   1. The DSA key is only used for authenticating in the AKE 
> (authenticated key exchange, which builds upon Diffie-Hellman). This 
> way, either party can prove that they talked to each other. The AKE 
> results in a symmetric key, shared by both parties. Note that they
> don't authenticate the messages themselves.
> 
>   2. Each actual data message is encrypted using the symmetric key 
> mentioned above, and authenticated using a MAC (which uses a key
> which is derived from the symmetric session key as well).
> 
>   3. Frequently (from the top of my head, I think this is on each 
> message) a new session key will be exchanged and the keys used for 
> encryption and the keys used for MACs are renewed. The old keys used
> for the MACs will be revealed to everyone. This is the function that 
> provides the deniability, because at this point in time, anyone can 
> forge messages that would've been valid earlier.


OK...I get it...Mostly.  The authentications can be faked by a third
party.  Nevertheless, from a practical standpoint of me chatting with
an adversary...I still feel more comfortable not relying on that.  For
use with tor, when anonymity is a concern, you want to avoid having
anything that identifies you again and again, like this sha1 dsa
fingerprint.  For that purpose, I feel more comfortable using a simple
shared secret like "sugar" or something.  Even if neither
method is "proof" that I signed the keying material...I just feel
better about new dsa key for every conversation...maybe I don't
understand the spec enough and I will check it out more.


> 
>   So much for cryptographic authentication. Now you only have to
> prove that the DSA keys your partner used to identify himself indeed
> is his. And this is where either fingerprint verification or SMP
> comes up. These are used to verify that you did not talk to a
> man-in-the-middle, or someone completely
>   Now this is the sort of manual authentication you do for TOR as
> well: you exchange on a secure channel (preferably face-to-face) your
> hidden service address, or your OTR fingerprint (or your SMP secret).
> 
> On 2013-02-19 19:13, Ileana wrote:
> > DH prime group:  2048-4096 bits
> > Hash function:  at least SHA-256
> > AES key length:  256 bits
> >
> > In OTR's favor, the amount of cipher text is small, reducing some
> > crypt-analysis efforts.
> >
> > So not a crypto expert (but learning)  but I can read
> > www.keylength.com and see that OTR does not meet recommendations
> > for forward security.
> 
>   While the Hash length and DL group size may be valid suggestions
> (I'm no expert in cryptanalysis), I don't see where you got the AES
> key size=256bit from (your source lists symmetric keys with 128 bits
> until 2040).
>   You shouldn't forget to be scared about the asymmetric keys though: 
> most DSA implementations currently don't support keys above
> 1024bit. ;-)

OK.  Thanks for this update!  And you are right....I was looking at the
discreet log key length...which is for dh--I don't know if that is
for el/gamel for instance or symmetric keys generated by dh.  I have
having problems finding a source that specifies key lengths to be used
from the dh, if that is different then you would use for normal aes for
example.

NSA recommends AES-256 for topsecret communication...
https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml

"AES with 128-bit keys provides adequate protection for classified
information up to the SECRET level. Similarly, ECDH and ECDSA using the
256-bit prime modulus elliptic curve as specified in FIPS PUB 186-3 and
SHA-256 provide adequate protection for classified information up to
the SECRET level. Until the conclusion of the transition period defined
in CNSSP-15, DH, DSA and RSA can be used with a 2048-bit modulus to
protect classified information up to the SECRET level.

AES with 256-bit keys, Elliptic Curve Public Key Cryptography using the
384-bit prime modulus elliptic curve as specified in FIPS PUB 186-3 and
SHA-384 are required to protect classified information at the TOP
SECRET level. Since some products approved to protect classified
information up to the TOP SECRET level will only contain algorithms
with these parameters, algorithm interoperability between various
products can only be guaranteed by having these parameters as options. "

top secret for otr sounds fine with me.  Let some other part of the
system be the weakest link...not the otr...and as far as the sha1...it
seems otr just uses that for fingerprints not encryption/key gen.

so thanks agian.