[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cryptography-randombit
Subject:    Re: [cryptography] Is KeyWrap (RFC 3394) vulnerable to CCAs?
From:       Peter Gutmann <pgut001 () cs ! auckland ! ac ! nz>
Date:       2015-01-06 10:56:28
Message-ID: E1Y8RoK-0005Ko-RO () login01 ! fos ! auckland ! ac ! nz
[Download RAW message or body]

Naveen Nathan <naveen@lastninja.net> writes:
>[Quoting someone else]
>> As I see it from that paper the advantages of a key-wrap scheme over using a
>> generic AEAD scheme is that
>>
>> (a) it may be lighter weight in computation and size of ciphertext
>> (b) Defends against "IV misuse".
>> (c) RFC 3394 has been around for a while and is widely available
>
>The suggested mode of operation for keywrap is SIV mode which is both
>documented in the above paper and in RFC5297. It provides deterministic CCA
>encryption but fails the indinguishabiltiy under eavesdropping experiment
>(any two ciphertexts encrypted under a given key that are equal correspond to
>the same plaintext).

There's another key wrap mechanism for CMS used with PWRI, originally 
documented in RFC 3211.  RFC 3394 exists because NIST had invented a key wrap 
mechanism for AES and the RFC was created in order to specify its use with 
CMS.  RFC 3211 is a general-purpose (not tied to AES) key wrap mechanism. Note 
that it's malleable (due to use of CBC-MAC), but that's because it uses a 
primitive from a decade earlier that's been reasonably well-analyzed, and it's 
not obvious that it's a practical weakness or not (you can cause a partial 
garble of the key resulting in a decrypt failure, but flipping a bit in the 
ciphertext will do the same thing).  See Adam Back's original post:

http://marc.info/?l=cypherpunks&m=102010629817844&w=2

and my followup:

http://marc.info/?l=cypherpunks&m=102105438817072&w=2

Summary:

  It's amazing that there doesn't seem to be any published research on such a
  fundamental crypto mechanism, with the result that everyone has to invent
  their own way of doing it, usually badly.  We don't even have a decent
  threat model for this
  
  [...]

  The design goals I used were:

  1. Resistance to dictionary/password-guessing attacks above all else.

  2. No need to use additional algorithms like hash algorithms (see the RFC for
     the rationale, to save me typing it all in again).

(A third one, not explicitly stated there, is "Use an existing, analysed
mechanism rather than inventing yet another new one").

Peter.


_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


[prev in list] [next in list] [prev in thread] [next in thread]