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

List:       ipsec
Subject:    Re: [IPsec] everything old is new again
From:       "Dan Harkins" <dharkins () lounge ! org>
Date:       2015-03-17 2:48:58
Message-ID: f1dc6e6e90823ea446cd3b41233e816b.squirrel () www ! trepanning ! net
[Download RAW message or body]


  And of course by, "does this implicit construction imply some
kind of concatenation=85" I don't mean concatenation at all. I
mean some sort of chopping off 32 bits. Sorry for the confusion.

  Dan.

On Mon, March 16, 2015 4:37 pm, Dan Harkins wrote:
>
>   Hello,
>
>   I'm leaving too early to attend the ipsecme meeting at IETF 92
> but I notice that draft-mglt-6lo-aes-implicit-iv is on the
> agenda as "other documents".
>
>   The idea of using an implicit IV was brought up in the IPsec WG
> back in 1997 and rejected (yes, this was just for CBC mode but
> that's because CCM and GCM were not designed yet). Why is
> this a good idea now?
>
>   The "unpredictable"-ness of an IV for CBC mode addresses a
> chosen plaintext attack that would otherwise reduce CBC mode
> down to ECB mode (and enable a codebook attack). I _think_
> the draft addresses this because the IV ends up being secret
> but that requires reading a bit into section 4. Namely, does one
> take the "clear text payload" as plaintext and the "dedicated 16
> byte key" as the key for a single ECB-style encryption using AES?
> It says there's a payload and a key and it says AES is used as
> a PRP but no normative text to say exactly what to do to get
> this IV.
>
>   Also, if that is the way the IV is (secretly) generated then does
> this propose using a 128-bit IV, the block length of AES, for GCM?
> Most implementations use the default 96-bit IV so does this
> implicit construction imply some kind of concatenation or does
> it propose to use a 128-bit IV with GCM? SP 800-38D describes
> an RBG-based IV construction, is that what this draft is doing?
>
>   As an aside, the Security Considerations of this draft need work.
> It says that IV generation "has been left to the implementation as
> long as certain security requirements are met." What are they? Do
> the different modes have different requirements?  Are these
> requirements met by this draft? If so, how?
>
>   regards,
>
>   Dan.
>
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[prev in list] [next in list] [prev in thread] [next in thread]