Subject: [TLS] ChaCha and IVs

From: Stephen Kent <[email-masked]>
Date: Tue, 04 Mar 2014 11:53:39 -0500

For those who did not attend or remotely participate in the TLS WG meeting
on 3/4/14, EKR suggested that I draw your attention to the slides I 
presented.

The focus of my presentation was a suggestion that ChaCha, when its used 
as a
cipher suite for DTLS, use an explicit IV for the per-packet unique value,
not re-use the DTLS record number (to save space).

I reviewed several reasons for this, based on discussions that took place in
the IPsec WG several years ago, when we considered the same topic for 
AES counter
mode use with ESP. We decided to require each packet to carry an IV 
independent of
the ESP sequence number (or extended sequence number). Slide 5 of my 
presentation
enumerates reasons for not re-using a packet/record sequence number for 
an IV.
I also noted (Slide 3) that the proposal to use ChaCha with ESP follows the
approach we have adopted for other algorithms, and thus it is preferable 
that
DTLS use the same approach, to enable common hardware and software 
implementations
to support both protocols.

Steve

---

From: Adam Langley <[email-masked]>
Date: Tue, 4 Mar 2014 11:57:13 -0500

> on 3/4/14, EKR suggested that I draw your attention to the slides I

Are the slides available anywhere?

Cheers

AGL

---

From: Watson Ladd <[email-masked]>
Date: Tue, 4 Mar 2014 08:58:18 -0800

http://www.ietf.org/proceedings/89/slides/slides-89-tls-2.pdf

On Tue, Mar 4, 2014 at 8:57 AM, Adam Langley <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 04 Mar 2014 18:57:19 +0100

> enumerates reasons for not re-using a packet/record sequence number for 

Hello,
 I believe there advantages in using the record sequence number for an
IV _in TLS_, but before mentioning them, I'll make some comments on your
points.
 
> From a security assurance perspective, an IV based on a 
> protocol-supplied value expands the scope of what has to 
> be analyzed (to ensure uniqueness) 

In TLS the record sequence numbers are unique by definition, thus any
analysis is simplified.

> An algorithm implementation submitted for FIPS evaluation 
> must be independently evaluable 

>From the wording I don't understand how this is relevant to your point
for nonces. Could you elaborate?

> If DTLS and ESP adopt different IV approaches for the 
> same algorithm/mode, chip vendors have problems 

By problems I suppose that you mean that they have to implement a module
that works with both. 

> In some cases, a non-counter IV approach can be faster 
> than a counter (in hardware) 

I don't think that this is a good argument against implicit nonces. In
software the counter IV approach is always faster.

> Allowing each sender to choose its own IV generation 
> approach is more flexible 

Indeed, but flexibility in security protocols isn't an advantage, and I
don't see what is the actual gain from such flexibility.

So now for the arguments for using the record sequence number as (part
of) the nonce in TLS:
* It reduces the exchanged data (by 12 or 8 bytes - depending on the
explicit nonce size). This is particularly important in DTLS where the
typical record size is less than 1400 bytes.

* It ensures that the nonce is unique even until 2^64-1 records are
exchanged (which is the termination limit for TLS sessions).

regards,
Nikos

---

From: Stephen Kent <[email-masked]>
Date: Tue, 04 Mar 2014 13:15:01 -0500

Nikos,
> In TLS the record sequence numbers are unique by definition, thus any
Security evaluation for a crypto alg does not include a protocol like ESP or
(D)TLS; if focuses only on the alg implementation. Thus a TLS "guarantee"
of uniqueness is not relevant. Anyone who has had a product evaluated will
tell you that the goal is always to minimize the amount of code that is 
subject
to review. If one were to use a TLS (or ESP) sequence number for an IV, 
all of
the protocol code would be part of the evaluation, and that would make the
evaluation prolonged and very costly.
> for nonces. Could you elaborate?
As noted above, if one submits an implementation of AES (or, maybe 
later, ChaCha)
for evaluation by NIST or a NIST-certified lab, the alg implementation 
is evaluated
by itself, independent of any protocol. if you look at the FIPS 140-x 
list of evaluated
products you'll see that they are evaluated wrt crypto security, not wrt 
a protocol
that uses the crypto. This is true even if a product is a crypto 
accelerator for IPsec
or TLS.
> By problems I suppose that you mean that they have to implement a module
yes.
> software the counter IV approach is always faster.
yes, but software is not the only game in town. If thousands of sessions 
terminate
at a collection of servers it has been common practice to use hardware 
to offload the
processing from the servers. This also affords better protection to the 
traffic keys.
> don't see what is the actual gain from such flexibility.
In this case the flexibility is desirable because it allows different
implementations to decide how to manage the IVs, as senders, without
the need to coordinate with receivers.
> typical record size is less than 1400 bytes.
The typical packet size in the ESP context is at least that small.
> exchanged (which is the termination limit for TLS sessions).
this guarantee is only as good as the assurance of the TLS code than manages
the sequence numbers, which is not likely to be secure as the alg 
implementation.

Steve

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 4 Mar 2014 13:18:22 -0500

> In TLS the record sequence numbers are unique by definition, thus any analysis is simplified.

Ever done a FIPS or similar certification?  You have to give them your source code.  You really don't want to require the TLS stack to be included in that bundle when all you want is certified crypto.

	/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, M

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 04 Mar 2014 18:29:59 +0000

> for nonces. Could you elaborate?

In the case of AES-GCM there are some requirements for how the IV is generated
for FIPS (and FIPS 140-2) compliance.

It has been a while since I looked at this in detail but from memory it
effectively meant the explicit part of the IV had to be generated by the module
itself on encrypt (various schemes were permissible). An application couldn't
specify an arbitrary value which would seem to preclude the use of the sequence
number directly.

So on encrypt you'd typically call the module to generate the explicit part of
the IV and then use that generated value in the protocol (for TLS copy it to the
explicit IV part of the record).

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Adam Langley <[email-masked]>
Date: Tue, 4 Mar 2014 13:24:57 -0500

> Ever done a FIPS or similar certification?  You have to give them your source code.  You really don't want to require the TLS stack to be included in that bundle when all you want is certified cryp…

If you wish to certify an AEAD you only need to provide the code for
an AEAD. The nonce input is well specified and has uniqueness
requirements. In the same way, the key in a traditional cipher also
has uniqueness requirements, but I don't believe that the full TLS
key-agreement needs to be included.

Cheers

AGL

---

From: Adam Langley <[email-masked]>
Date: Tue, 4 Mar 2014 13:17:09 -0500

Here are the points from the slides:

> From a security assurance perspective,
> an IV based on a protocol-supplied value
> expands the scope of what has to be
> analyzed (to ensure uniqueness)

The uniqueness of the sequence number is needed to ensure that records
cannot be reordered so you cannot get away from having to establish
that property.

> An algorithm implementation submitted for FIPS evaluation must be independently evaluable.

An evaluation already assumes properties - i.e. that the key is
actually secret! The interface and assumptions of an AEAD are well
established (https://tools.ietf.org/html/rfc5116) and include an nonce
input that must be unique for a given key.

> same algorithm/mode, chip vendors have problems

ChaCha is not the hardware orientated cipher in any case, but I'm
unconvinced this is true. So far, hardware implementations that I've
seen take the nonce as an input, which is also the obvious design from
my point of view.

> than a counter (in hardware)

A non-counter IV is not safe unless the nonce is significantly
extended. Certainly, nobody should never use a non-counter IV with
AES-GCM in TLS. In any case, I think significant evidence would be
needed to show that the performance of this outweighs the cost of
wasting ~16 bytes / record.

> approach is more flexible.

It's flexible in the same way that AES-GCM in TLS is flexible: i.e.
that I had to survey all the implementations to ensure that nobody has
used a random IV because that's unsafe. I don't want that sort of
flexibility!

Cheers

AGL

---

From: Adam Langley <[email-masked]>
Date: Tue, 4 Mar 2014 13:56:31 -0500

On Tue, Mar 4, 2014 at 1:29 PM, Dr Stephen Henson
<[email-masked]> wrote:
> itself on encrypt.

I feel this is a problem that FIPS needs to sort out (they don't have
a concept of an AEAD, I assume).

I'm unwilling to have the whole world waste bandwidth, and have a more
dangerous specification, because of a bureaucratic problem.

Cheers

AGL

---

From: Wan-Teh Chang <[email-masked]>
Date: Tue, 4 Mar 2014 11:44:05 -0800

Hi,

I researched the FIPS validation of AES-GCM recently. My conclusion
was that using an externally-provided nonce/IV for AES-GCM is
acceptable for FIPS 140-2 validation.

Details:

On the NIST AES algorithm validation list
(http://csrc.nist.gov/groups/STM/cavp/documents/aes/aesval.html),
please search for "GCM". You will see several validated GCM
implementations with "IV Generated: ( Externally )".

A specific example that you can inspect easily is AES Certificate
#2216, for the CNG in Windows 8:
http://csrc.nist.gov/groups/STM/cavp/documents/aes/aesval.html#2216

This AES algorithm certificate is part of FIPS 140-2 validation
certificate #1892
(http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2013.htm#1892).
Its security policy states that the BCryptEncrypt  function is used
for AES-GCM encryption. The BCryptEncrypt function requires the caller
to provide the nonce for AES-GCM. See the pbNonce field of the
BCRYPT_AUTHENTICATED_CIPHER_MODE_INFO structure described at
http://msdn.microsoft.com/en-us/library/windows/desktop/cc562981(v=vs.85).aspx

So I concluded that an AES-GCM implementation that only accepts
externally-provided nonce/IV can still be FIPS validated.

Also, in certain cases, a crypto module can verify that the
externally-provided nonces/IVs are not repeated. For example, if the
nonces are generated by a counter, the crypto module can easily verify
they are monotonically increasing. This approach as an alternative to
an internal IV generator is also described in David McGrew's draft:
https://tools.ietf.org/html/draft-mcgrew-iv-gen-03#section-5.1

Note: I worked on the FIPS 140-2 validation of a software crypto
module at Level 2
(http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2007.htm#814),
so I am not completely ignorant of FIPS validation issues.

Wan-Teh Chang

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 04 Mar 2014 20:22:41 +0000

> acceptable for FIPS 140-2 validation.

I'd be interested to know if that has changed in the last few years. We had to
go to quite a bit of trouble specifying how the IV was generated in some
detail... an experience I'd have gladly avoided.

Steve.

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 04 Mar 2014 20:48:14 +0000

> detail... an experience I'd have gladly avoided.

Weird... I went back through my old notes and found a reference to FIPS140-2
Implementation Guidance (IG):

http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf

In section A.5 are some comments about AES-GCM including this:

	1. The external generation of the IVs is not allowed.

Steve.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 4 Mar 2014 18:11:34 -0500

> I'm unwilling to have the whole world waste bandwidth, and have a more dangerous specification, because of a bureaucratic problem.

For eight bytes.  Shrug, okay, your battle (if, in fact, it is; Wan-Teh could be rightr).

Nothing prevents TLS from saying the nonce should be the record number.  Careful implementations could compare them.

Your company may not care about FIPS, but many TLS users/providers do.

	/r$

Cambridge, MA

---

From: Brian Smith <[email-masked]>
Date: Tue, 4 Mar 2014 15:17:22 -0800

> evaluation prolonged and very costly.

ChaCha20-Poly1304 can't be validated anyway, even if it used explicit IVs,
because it isn't an algorithm that has been approved by any agency that
requires validation.

One can have the crypto component generate the ciphertext and the counter
IV in a way that is guaranteed to be a monotonically increasing sequence.
This code would be the code that would be validated. Then, have your TLS
implementation take that counter IV that was output from the crypto
component and verify that it matches the current record number, and fail if
there is a mismatch.

Certification programs exist, in theory, to ensure that we do good, safe
things. In this case, we have a bit of bureaucracy that is getting in the
way of doing something that is clearly good and safe. The best solution to
that problem is to fix the bureaucracy. If one cannot fix the bureaucracy
then one can simply avoid implementing ChaCha20-Poly1304 and implement
AES-GCM or other cipher suites instead.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

---

From: Adam Langley <[email-masked]>
Date: Tue, 4 Mar 2014 18:18:56 -0500

> For eight bytes.  Shrug, okay, your battle (if, in fact, it is; Wan-Teh could be rightr).

8 bytes is ~0.6% of bandwidth assuming that one is sizing records to
packets. It's not huge, but it's not trivial.

> Your company may not care about FIPS, but many TLS users/providers do.

I understand, but I'm quite happy to apply pressure to FIPS to be
reasonable here.

Cheers

AGL

---

From: Brian Smith <[email-masked]>
Date: Tue, 4 Mar 2014 15:35:04 -0800

> Your company may not care about FIPS, but many TLS users/providers do.

There is a difference between not caring about FIPS and believing that the
solution to this conflict is to fix the validation requirements. If we were
to require everything that IETF does to conform to NIST requirements then
NIST would effectively have veto power over everything that the IETF does.
That should never be the case.

Cheers,
Brian

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 4 Mar 2014 19:35:19 -0500

>There is a difference between not caring about FIPS and believing that the solution to this conflict is to fix the validation requirements.
Engineering, especially security, is a trade-off. Sometime the trade-offs are which battles to fight.
> If we were to require everything that IETF does to conform to NIST requirements then NIST would effectively have veto power over everything that the IETF does. That should never be the case.
Did I give you the impression that I said anything close to this?

Sonny, I posted DES to Usenet back in the Dark Ages and then arranged to get it re-posted from Australia (search for “des-no-usa”, quotes probably required).  Have some respect ☺

                /r$

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 05 Mar 2014 08:13:53 +0100

On Tue, 2014-03-04 at 13:18 -0500, Salz, Rich wrote:
> Ever done a FIPS or similar certification?  You have to give them your
> source code.  You really don't want to require the TLS stack to be
> included in that bundle when all you want is certified crypto.

I didn't say that FIPS (or any other) certification will be simplified.
I said analysis meaning security analysis.

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 05 Mar 2014 08:19:20 +0100

> evaluation prolonged and very costly.

I believe this was answered elsewhere in this thread.

> the sequence numbers, which is not likely to be secure as the alg 

One cannot design protocols with the assumption that they will be
violated. However, even if you are implying that implementations will
continue to exchange data even after 2^64-1 records are exchanged, then
the counter nonce approach will fail precisely at the 2^64 exchanged
record. The random nonce approach will fail much earlier.

regards,
Nikos

---

From: Alyssa Rowan <[email-masked]>
Date: Wed, 05 Mar 2014 13:28:31 +0000

(Just popping by briefly on this one.)

On 04/03/2014 18:56, Adam Langley wrote:

> I feel this is a problem that FIPS needs to sort out (they don't
> have a concept of an AEAD, I assume). I'm unwilling to have the
> whole world waste bandwidth, and have a more dangerous
> specification, because of a bureaucratic problem.

A strong +1 on this.

Random IVs risk collision earlier, burn valuable entropy faster, and
are far more fragile.

Sequential IVs are deterministic, verifiable, debuggable, and implicit.

It is crystal-clear to me that sequential IVs are the correct
approach. I would be interested to hear NIST's reasons for
recommending otherwise.

ChaCha20 and Poly1305 are, of course, not in the FIPS catalogue, so
it's moot.

In a wider sense, given recent discoveries about extremely critical
parts of widely-used TLS stacks, perhaps limiting the scope of reviews
to crypto primitives would be unwise in any event: certified crypto
doesn't do any good when it's skipped over.

- -- 
/akr

---

From: Adam Langley <[email-masked]>
Date: Wed, 5 Mar 2014 08:38:43 -0500

> approach. I would be interested to hear NIST's reasons for

I don't believe that NIST actually *is* recommending random nonces.
The explicit nonce form allows for it, however, and that's why I
characterise it as "dangerous".

I believe the motivation for wanting an explicit nonce is so that the
nonce management is contained "within" the AEAD. The AEAD then,
conceptually, returns a ciphertext block that includes the explicit
nonce as a prefix and thus, by considering the AEAD 'module' in
isolation, one can ensure that it doesn't duplicate nonces.

(Any such AEAD 'module' would need to use a counter internally when
the nonces are only 8 bytes for the reasons that you give.)

I think the disagreement is whether this conceptual partitioning is
worth the danger and overhead. (I'm claiming that it's not.)

Cheers

AGL

---

From: Dr Stephen Henson <[email-masked]>
Date: Wed, 05 Mar 2014 13:47:18 +0000

On 05/03/2014 13:28, Alyssa Rowan wrote:
> 
> Random IVs risk collision earlier, burn valuable entropy faster, and are
> far more fragile.
> 
> It is crystal-clear to me that sequential IVs are the correct approach. I
> would be interested to hear NIST's reasons for recommending otherwise.
> 

In the case of AES-GCM the relevant FIPS specifications *do* permit sequential
IVs. One permitted construction is a random starting point generated within
the module which is then incremented on each invocation.

That "random starting point" requirement means you can't use the sequence
number directly though.

One way round that would be to have a way to specify the starting point. An
explicit IV in the first record for example, but that looks messy to me.

Steve.

---

From: Sandeep Kumar <[email-masked]>
Date: Wed, 5 Mar 2014 18:25:23 +0100

> packets. It's not huge, but it's not trivial.
For constrained environments where we try to fit everything within a 127
byte of the 802.15.4 frame to avoid fragmentation, 8 bytes of additional IV
is going to be a deal breaker for this cipher suite to be used in DTLS for
such environments. Prefer there is no such unnecessary ciphertext expansion.

Sandeep

---

From: Robert Cragie <[email-masked]>
Date: Wed, 05 Mar 2014 17:44:24 +0000

This seems to be a non-issue to me. In SP 800-38D section 8.2.1, the 
deterministic construction is described using an IV with an invocation 
field. If the invocation field is specified as an integer counter, it 
will, by definition, increment by one every time the AES-GCM encrypt 
function is invoked for a particular key. Maybe I missed it, but I 
didn't notice the requirement that the invocation field starts at a 
random starting point? Therefore, this could start at 0 on provision of 
a new key and also be the basis of the sequence number. If there is 
insistence that this is generated within a cryptographic module for 
validation purposes, in the TLS case, the module would use the 
deterministic construction with the invocation field as an integer 
counter and export the invocation field to form the TLS sequence number. 
In this way, there would be no need to have to supply any additional 
code as part of the validation.

Robert

---

From: Dr Stephen Henson <[email-masked]>
Date: Wed, 05 Mar 2014 18:45:21 +0000

On 05/03/2014 17:44, Robert Cragie wrote:
> deterministic construction is described using an IV with an invocation field. If
> the invocation field is specified as an integer counter, it will, by definition,
> increment by one every time the AES-GCM encrypt function is invoked for a
> particular key. Maybe I missed it, but I didn't notice the requirement that the
> invocation field starts at a random starting point? Therefore, this could start
> at 0 on provision of a new key and also be the basis of the sequence number. If
> there is insistence that this is generated within a cryptographic module for
> validation purposes, in the TLS case, the module would use the deterministic
> construction with the invocation field as an integer counter and export the
> invocation field to form the TLS sequence number. In this way, there would be no
> need to have to supply any additional code as part of the validation.
> 

SP800-38D is combined with the FIPS 140-2 implementation guidance (IG) during
FIPS 140-2 validation. In this case IG A.5 is relevant for AES-GCM and IVs.

The IG can modify the requirements of other standards (e.g. restrict them) for
the purposes of FIPS 140-2. A deterministic IV from SP800-38D 8.2.1 looks like
it falls under IG A.5 3.A:

"A. Each deterministically established IV shall include an encoding of the
module’s name and the name shall be long enough to allow for at least 32^2
different names."

Which presumably isn't something we'd do for TLS.

There is of course some guesswork involved here in that any future FIPS spec and
IG would be similar to that for AES-GCM. In the case of AES-CCM there aren't any
IV internal generation requirements AFAIK.

Steve.

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 5 Mar 2014 16:35:01 -0800

Stephen Kent <[email-masked]>:

Anyone who has had a product evaluated will
> evaluation prolonged and very costly.

I suppose if this becomes an actual concern for evaluation, you could
create a more easily evaluable module that accepts explicit IVs but checks
that these increase monotonically between invocations.  (Accepting
*explicit* IVs doesn't mean you have to accept *arbitrary* IVs.)

(Implicitly, this would also enforce the TLS requirement that sequence
numbers are not allowed to wrap around once you're beyond 2^64 records.)

---

From: Nico Williams <[email-masked]>
Date: Wed, 5 Mar 2014 18:59:05 -0600

On Wed, Mar 5, 2014 at 6:35 PM, Bodo Moeller <[email-masked]> wrote:
> I suppose if this becomes an actual concern for evaluation, you could create
> a more easily evaluable module that accepts explicit IVs but checks that
> these increase monotonically between invocations.  (Accepting *explicit* IVs
> doesn't mean you have to accept *arbitrary* IVs.)

This.

However in the DTLS case there's no way to make the sequence numbers
be monotonic.  What the module could do is keep its own IV sequence
number window and reject the use of sequence numbers that are too old
or reused...

...but note that in the decrypt case it may still be useful to know
that a message is a replay and yet get the authentication tag state
and plaintext outputs.  The GSS-API's GSS_Unwrap() function supports
this.

Having a sequence number window in the algorithm module is a PITA, but
much less a PITA than having to validate all of a TLS implementation.

> numbers are not allowed to wrap around once you're beyond 2^64 records.)

And if the IV must initially be randomly chosen, let the module
generate it but let the user (TLS) furnish the sequence numbers to add
to the initial IV to get the actual IV.

Of course, this does mean that on decrypt the algorithm module will
have to output the sequence number/IV.

So this is really an exercise in designing an API to the cipher+mode
that allows the provider to be validated separately from the user
application, and still provide desired assurances to the validator.

Nico
-- T

---

From: Andy Lutomirski <[email-masked]>
Date: Wed, 05 Mar 2014 17:19:23 -0800

> number window and reject the use of sequence numbers that are too old

DTLS is fine with strictly monotonic *encryption* sequence numbers,
right?  And I don't think it's a problem if an AEAD is asked to
*decrypt* repeated sequence numbers.  (It's certainly a problem if an
attacker can access the decryption of two different messages with the
same sequence if they don't both verify, but this is solvable by having
the crypto implementation refuse to supply the supposed plaintext if the
tag is bad.)

--Andy

---

From: Nico Williams <[email-masked]>
Date: Wed, 5 Mar 2014 19:27:31 -0600

> right?  And I don't think it's a problem if an AEAD is asked to

But DTLS is intended to be used with transports that do not guarantee
in-order delivery, so on the receive side at least there's a need to
permit out-of-order sequence numbers.

On the send side too, for concurrency reasons, there's a need to
permit out-of-order generation.  (N threads sharing a DTLS connection,
each using an atomic increment operation to get the next sequence
number, then proceeding at their own pace do to the rest.)

> *decrypt* repeated sequence numbers.  [...]

As long as the app gets the sequence number out so it can check for replays...

Nico
--

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 5 Mar 2014 17:37:47 -0800

> create

Right -- sorry, when I wrote the above, I only meant a check when
*en*crypting. *De*cryption is normally expected to have to handle
potentially arbitrary explicit IVs, anyway: for example, if encryption uses
random IVs, decryption will just have to accept these -- you wouldn't be
generating random IVs in the decryption module too :-).

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 5 Mar 2014 17:41:41 -0800

Bodo Moeller <[email-masked]>:

> *en*crypting.

(And accordingly, IVs *can* be monotic even with DTLS, as Andy has already
pointed out.  This isn't a property that the receiver can check, but if we
were to add explicit random IVs in addition to the explicit DTLS sequence
number, that clearly wouldn't provide anything for the receiver to check
either.)

---

From: Nico Williams <[email-masked]>
Date: Wed, 5 Mar 2014 19:48:10 -0600

> generating random IVs in the decryption module too :-).

Again, the module might check a sequence number window of its own.
And on the encryption side you should want a threaded program to be
able to encrypt out of order.  DTLS' out of order functionality is not
(or need not be) just in case the transport reorders.

Nico
--

---

From: Dr Stephen Henson <[email-masked]>
Date: Thu, 06 Mar 2014 02:04:31 +0000

On 06/03/2014 01:37, Bodo Moeller wrote:
> 
> Right -- sorry, when I wrote the above, I only meant a check when *en*crypting.
> *De*cryption is normally expected to have to handle potentially arbitrary
> explicit IVs, anyway: for example, if encryption uses random IVs, decryption
> will just have to accept these -- you wouldn't be generating random IVs in the
> decryption module too :-).
> 

I can confirm that and I did specifically ask about it: there are no "generated
internally in the module" IV requirements for decryption it can be explicitly
stated in an API call.

Steve.

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 5 Mar 2014 18:33:47 -0800

Nico Williams <[email-masked]>:

> Bodo Moeller <[email-masked]> wrote:
>

> (or need not be) just in case the transport reorders.

I do understand that, but we have three competing optimization goals here:

- Keep the code requiring FIPS evaluation (if that's required) as small as
possible.
- Avoid the overhead of an explicit IV [as a side-effect, improving
security -- a counter is better than random IVs].
- Allow optimal parallelization.

Pick any two.  For example, if you introduce random IVs to allow concurrent
encryption by multiple threads in a more easily evaluable encryption
module, while encryption can get faster, the explicit IV also means you end
up with more data to send.  It's not clear why that would be the best
trade-off.

Bodo