[Ach] about the 3DES thing again

[Aaron Zauner]

We’re aware of that and that’s basically the reason why we excluded them from our TLS configurations.

My issue still being: Why include a paragraph on 3DES then anyways? I think that’s pretty useless. And does not apply to TLS/SSL.

Aaron

On 03 Dec 2013, at 14:15, ianG <iang at iang.org> wrote:

> The problem with t-des in all of its variants is that it is a 64 bit block cipher.  This makes it vulnerable to rainbow tables, which puts a ceiling on its overall security.
> 
> Modern ciphers are typically 128 bit block sizes.  In March at FSE, DJB was opining that even 128 bits may be too small...
> 
> So, t-des and des and *all 64 bit block ciphers* and their variants are more or less deprecated.
> 
> 
> 
> iang
> 
> On 3/12/13 02:41 AM, Aaron Zauner wrote:
>> Hi,
>> 
>> I gave some thought to what we discussed during the meeting. To keep people on track: We were talking whether we should add or remove the paragraph on 3DES that currently states:
>> 
>> ```
>> One special remark is necessary for 3DES: here we want to note
>> that it theoretically has 168 bit security, however based on the NIST Special
>> Publication 800-57
>> \footnote{\url{http://csrc.nist.gov/publications/PubsSPs.html\#800-57-part1},
>> pages 63 and 64}, it is clear that 3DES is only considered 80 bits / 112 bits.
>> ```
>> This needs further discussion and feedback from other people on the ML.
>> 
>> My opinion:
>> 
>> 1) We are critical of NIST (a bit too critical in my opinion) - yet we include a reference to a NIST publication citing security concerns with 1 or 2 key variants of 3DES (usually 3 keys for each iteration, yielding 168bit security)
>> 2) I cannot find any popular SSLv3 library implementing 3DES with only one or two keys. [0] [1] [2]
>> 3) So after all.. we exclude 3DES in example configurations, why include a statement on 3DES implementations that are not relevant to the paper? I’m sure they are out there. But they do not matter for us, right?
>> 
>> Thanks,
>> Aaron
>> 
>> 
>> [0] - https://github.com/openssl/openssl/blob/master/crypto/des/des_enc.c
>>      - https://github.com/openssl/openssl/blob/master/crypto/des/des.h
>> ```
>> void DES_ede3_cbcm_encrypt(const unsigned char *in,unsigned char *out,
>>                            long length,
>>                            DES_key_schedule *ks1,DES_key_schedule *ks2,
>>                            DES_key_schedule *ks3,
>>                            DES_cblock *ivec1,DES_cblock *ivec2,
>>                            int enc);
>> ```
>> 
>> [1] - https://polarssl.org/des-source-code
>> ```
>> #define DES_KEY_SIZE    8
>> …
>> typedef struct
>> {
>> int mode;                   /*!<  encrypt/decrypt   */
>> uint32_t sk[96];            /*!<  3DES subkeys      */
>> }
>> des3_context;
>> ```
>> 
>> [2] - http://git.savannah.gnu.org/cgit/gnutls.git/tree/lib/nettle/cipher.c?id=0d004a210db5d220c896456a165c81264fa4454a#n76
>>      - http://git.lysator.liu.se/nettle/nettle/blobs/master/des3.c#line36
>> ```
>> int
>> des3_set_key(struct des3_ctx *ctx, const uint8_t *key)
>> {
>>   unsigned i;
>>   int is_good = 1;
>> 
>>   for (i = 0; i<3; i++, key += DES_KEY_SIZE)
>>     if (!des_set_key(&ctx->des[i], key))
>>       is_good = 0;
>> 
>>   return is_good;
>> }
>> ```
>> 
>> 
>> 
>> _______________________________________________
>> Ach mailing list
>> Ach at lists.cert.at
>> http://lists.cert.at/cgi-bin/mailman/listinfo/ach
>> 
> 
> _______________________________________________
> Ach mailing list
> Ach at lists.cert.at
> http://lists.cert.at/cgi-bin/mailman/listinfo/ach

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1091 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.cert.at/pipermail/ach/attachments/20131203/bbbb8070/attachment.sig>