[asterisk-dev] [Code Review] Allow Setting Bitsize and make SRTP optional chan_sip

[Tilghman Lesher]

> On 2011-05-21 11:18:21, Tilghman Lesher wrote:
> > 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.
> 
> irroot wrote:
>     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.
>     
>     
>
> 
> Tilghman Lesher wrote:
>     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.
> 
> bbeers wrote:
>     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
>
> 
> irroot wrote:
>     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.

Okay, then the code is a source of confusion.  Let's change the constants within the code to make it clear that it's the authtag that is 32-bits not the bit strength of the encryption.


- Tilghman


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1173/#review3588
-----------------------------------------------------------


On 2011-05-21 06:41:17, irroot wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1173/
> -----------------------------------------------------------
> 
> (Updated 2011-05-21 06:41:17)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> 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.
> 
> 
> This addresses bug 19335.
>     https://issues.asterisk.org/view.php?id=19335
> 
> 
> Diffs
> -----
> 
>   /team/irroot/t38gateway-trunk/channels/chan_sip.c 319935 
>   /team/irroot/t38gateway-trunk/channels/sip/include/sdp_crypto.h 319935 
>   /team/irroot/t38gateway-trunk/channels/sip/include/sip.h 319935 
>   /team/irroot/t38gateway-trunk/channels/sip/include/srtp.h 319935 
>   /team/irroot/t38gateway-trunk/channels/sip/sdp_crypto.c 319935 
> 
> Diff: https://reviewboard.asterisk.org/r/1173/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> irroot
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110521/95159e6c/attachment.htm>