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

[irroot]

> 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
>

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.


- irroot


-----------------------------------------------------------
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/87bcb014/attachment-0001.htm>