<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">It may not provide the same deniability aspects</blockquote><div><br>the third type of mikey key agreement uses signed diffie-hellman "half-keys", like otr. perfect forward secrecy, and plausible deniability. granted though, it may not use a type of aes where a substitution is plausible. of course, your voice is hard to deny anyway.
<br> </div><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">and if the D-H is only done once<br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
per session, your forward secrecy window may be very large.</blockquote><div><br><a href="http://www.networksorcery.com/enp/rfc/rfc3711.txt">rfc 3711</a> states:<br><br><div style="margin-left: 40px;"><span style="font-family: arial,sans-serif;">
SRTP provides for some additional features. They have been</span> <br><span style="font-family: arial,sans-serif;">introduced to lighten the burden on key management and to</span> <br><span style="font-family: arial,sans-serif;">
further increase security. They include:</span><br style="font-family: arial,sans-serif;"><br style="font-family: arial,sans-serif;"><span style="font-family: arial,sans-serif;"> * A single "master key" can provide keying material for
</span><br style="font-family: arial,sans-serif;"><span style="font-family: arial,sans-serif;"> confidentiality and integrity protection, both for the SRTP stream</span><br style="font-family: arial,sans-serif;"><span style="font-family: arial,sans-serif;">
and the corresponding SRTCP stream. This is achieved with a key</span><br style="font-family: arial,sans-serif;"><span style="font-family: arial,sans-serif;"> derivation function (see Section 4.3), providing "session keys"
</span><br style="font-family: arial,sans-serif;"><span style="font-family: arial,sans-serif;"> for the respective security primitive, securely derived from the</span><br style="font-family: arial,sans-serif;"><span style="font-family: arial,sans-serif;">
master key.</span><br style="font-family: arial,sans-serif;"><br style="font-family: arial,sans-serif;"><span style="font-family: arial,sans-serif;"> * In addition, the key derivation can be <span style="font-style: italic;">
configured to periodically</span></span><br style="font-family: arial,sans-serif; font-style: italic;"><span style="font-family: arial,sans-serif;"><span style="font-style: italic;"> refresh</span><span style="font-weight: bold;">
</span>the session keys, which limits the amount of ciphertext</span><br style="font-family: arial,sans-serif;"><span style="font-family: arial,sans-serif;"> produced by a fixed key, available for an adversary to</span>
<br style="font-family: arial,sans-serif;"><span style="font-family: arial,sans-serif;"> cryptanalyze.</span><br style="font-family: arial,sans-serif;"><br style="font-family: arial,sans-serif;"><span style="font-family: arial,sans-serif;">
* "Salting keys" are used to protect against pre-computation and</span><br style="font-family: arial,sans-serif;"><span style="font-family: arial,sans-serif;"> time-memory tradeoff attacks [MF00] [BS00].
<br></span></div><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">It may not even provide authentication!</blockquote><div><br>mikey has three key agreement schemes, the third of which is similar to OTR, in that diffie-hellman is used with signed "half keys". the frustrating thing though, is that it uses "certificates", which have to be verifiable with some cert authority presumably. my feeling is that it should work like OTR, where even if you don't verify the fingerprint, it still "works", but just says "unauthenticated". and if you push some button on your phone, you can view either your session id hash or your fingerprint, and speak it to someone whose voice you know, to rule out a mim. one frustrating feature of minisip, is that it won't let you choose that type of mikey key agreement without putting in a digital cert first. argghhhhh..
<br><br><a href="http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-dhhmac-11.txt">this document</a> describes some alteration of this third scheme, to avoid the need for public keys. but i don't know how "keyed hashes" can remove the need for some sort of digital signature of the public dh generator "half keys".
<br><br>otr is fine and all, but when i get a little money saved up, and really get my underground anti-government resistance up and running, i want hard core deniable authenticated sip calls. i just wish the people behind srtp/mikey were as brilliant as you, ian.
<br><br>and back to the gaim issue. i guess their sip support will just be for text atm. funny, since instant messaging in sip is more of an afterthought, and nowhere near as robust as jabber. their voice support will be compatible with google talk..a proprietary system that google promises to switch to sip eventually anyway. argghhhh.
<br><br>thanks for the response,<br>clay<br></div></div>