<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://reviewboard.asterisk.org/r/1173/">https://reviewboard.asterisk.org/r/1173/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On May 21st, 2011, 11:18 a.m., <b>Tilghman Lesher</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Could you explain why anybody would want a 32-bit key? With today's processors, any conversation using such a key could be considered to be obscured, but not secured, because it's trivial to decrypt any message using such a short key length. We should be exploring longer key lengths, not shorter.</pre>
</blockquote>
<p>On May 21st, 2011, 11:32 a.m., <b>irroot</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Im with you 100% however Snom only works with 32bit this is a bit better than nothing and will add the support for these phones.
the patch makes it rather trivial to add additional lengths in the future.
we have cpl thousand snom phones out there so big win to support them better.
the patch on snoms website effectivly removes 80bit support this is worse.
</pre>
</blockquote>
<p>On May 21st, 2011, 12:47 p.m., <b>Tilghman Lesher</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">No, it's really NOT better than nothing. Using faulty encryption can lead to a false sense of security. No encryption is better than encryption that will not withstand a casual brute-force attack.
I agree with the part of the patch that allows greater bit strengths, but any bit strength lower than 80 bits (arguably, even 80 bits is weak) should be disallowed.</pre>
</blockquote>
<p>On May 21st, 2011, 1:12 p.m., <b>bbeers</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">The 32 vs. 80 bit part of the crypto_suite offer is for authentication_tag not encryption.
See http://tools.ietf.org/html//rfc4568#section-6.2
There are, as far as I know, only 3 defined crypto_suites
(all use 128 bit encryption key lengths):
AES_CM_128_HMAC_SHA1_80
AES_CM_128_HMAC_SHA1_32
F8_128_HMAC_SHA1_80
It appears that the F8_* support is optional but both AES_* are mandatory, from my reading
of RFC 4568 and RFC 3711.
Please see discussion and patches at https://issues.asterisk.org/view.php?id=18674
</pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">This patch consits of 3 parts.
1)allow "try" mode where encryption is attempted and fails to clear audio
2)use the cipher in the INVITE for the response
3)allow the option of setting 32bit mode in the INVITE
doing some homework i got this all wrong the 32bit / 80bit refers to the auth tag
32bit authtag seems to be AES-128 this is not weak
80bit authtag seems to be AES-192/256 this is strong
ill confess i know not the internal workings of SRTP perhaps this can be confirmed by
someone that the 32/80 is not the key strength ...
my goals are to improve interop and compatibility esp with devices we have widely deployed.</pre>
<br />
<p>- irroot</p>
<br />
<p>On May 21st, 2011, 6:41 a.m., irroot wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.orgrb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Asterisk Developers.</div>
<div>By irroot.</div>
<p style="color: grey;"><i>Updated 2011-05-21 06:41:17</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">change the encruption option to tristate with optional bit setting
also make this a global option.
qwell sugests a second option for bitlen have no problem with that.</pre>
</td>
</tr>
</table>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="https://issues.asterisk.org/view.php?id=19335">19335</a>
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>/team/irroot/t38gateway-trunk/channels/chan_sip.c <span style="color: grey">(319935)</span></li>
<li>/team/irroot/t38gateway-trunk/channels/sip/include/sdp_crypto.h <span style="color: grey">(319935)</span></li>
<li>/team/irroot/t38gateway-trunk/channels/sip/include/sip.h <span style="color: grey">(319935)</span></li>
<li>/team/irroot/t38gateway-trunk/channels/sip/include/srtp.h <span style="color: grey">(319935)</span></li>
<li>/team/irroot/t38gateway-trunk/channels/sip/sdp_crypto.c <span style="color: grey">(319935)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/1173/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>