[Cryptography] A new approach to encryption formats

[Phillip Hallam-Baker]

We have had PKCS#7, Cryptolopes and now JOSE for ages but none of them
really does what I want when designing a protocol.

In a protocol it is quite usual for the key exchange to be separate from
the encrypted data. It is also usual to want to amortize a key exchange
over multiple encrypted data chunks.

Traditional approaches for static data give me a key exchange that gives me
as output:

Encryption algorithm
Initialization vector
Encryption key
Authentication key (optional)

TLS does things differently of course but the key exchange is welded into a
protocol that assumes the ability to perform at least one round trip at
some point. For static data encryption, there is no synchronous
communication. But I still like the idea of separating out the key exchange
part and the key application part.

I would also like to eliminate as many code paths as possible. Thus I
always require a key wrap with a DH or ECDH operation so that messages with
multiple recipients are handled in the exact same fashion as messages with
one recipient.


So my key agreement structure has the following information

* The (default) bulk encryption/authentication algorithms and modes
* For each recipient key
    * Recipient key identifier
    * Encrypted key exchange data
    * Wrapped key [if a key agreement is used]

The wrapped key is the master secret.



Note that the IV is NOT part of this data. This is instead prepended to the
encrypted data chunk as follows:

[Length] [Header]
[Length] [Salt]
([Length'] [Non-terminal data chunk]) *
[Length] [Terminal data chunk]
[Length] [Trailer]

The tagging scheme allows terminal and non terminal chunks to be
distinguished. The trailer is only present if required by the bulk
algorithm.

The header slot is usually empty which incurs a one byte penalty per
message but provides a place to put the key exchange information if this is
desirable. This allows a Web server returning one encrypted item from a
sequence to present it as an atomic package similar to PKCS#7.

Alternatively the Header may be used to specify a key identifier for the
exchange.

The trailer slot is also mandatory (learned my lesson with HTTP chunking)
and is used to specify such authentication data as the bulk algorithms
mandate.


The IV and key(s) for the bulk encryption/authentication algorithm are
calculated from the master secret using the specified salt.

The main advantage of this approach is that correctly implemented, it
guarantees that a different key is used to encrypt each chunk of data even
when hundreds of chunks of data are encrypted under the same key.

The structure of the salt is opaque to the encryption format but MAY be
constructed from:

* A counter. This provides a means of recovering order from a sequence of
encrypted packets without additional data.

* A random value with 128 or more bits. This is interesting as it provides
a simple way to 'delete' data by simply overwriting the salt value with 0s.
This provides a 128 bit work factor for decryption if a 128 bit salt was
used.

* A counter plus a random value.

* A counter plus the authentication tag of the previous block. This
provides a handy means of providing a sufficiently random salt without
requiring additional data.


The approach should be compact enough to allow use on UDP data streams. The
absolute bare minimum overhead is 4 bytes (null header, trailer and salt,
data is 127 bytes or less).

If applied to field level data, I guess it might well be acceptable to drop
the header and trailer slots. This is not going to be viable for 'encrypt
in place' type applications so ciphertext stealing probably isn't relevant.


The consequences of this approach are as follows:

Pro:

* Multiple blocks of data are automatically encrypted under separate IVs
and Keys
* Supports all the functionality of PKCS#7 / JOSE
* Single processing path regardless of encryption options
* Straightforward format with no unnecessary hierarchy
* The encryptor has no direct control over the encryption key used.
* Supports embedded/detached key exchange modes and allows one to be
converted to the other.

Con:

* It is not possible to exchange previously encrypted data using this
format unless an option is provided to support an additional key wrap.
* The use of key wrap in the DH/ECDH exchange provides a subliminal channel
for the encryptor.


One of the really nice features of this approach is that it maps nicely to
a messaging service where we want to be able to encrypt summary data
(subject, recipients, sender) separately from bulk data.

A single 'email' might consist of a summary "These are the latest project
summary results, lets talk about them", a push message [The description of
the data] and an optional pull data item [several GB of raw data]. Alice
wants to send all three but Bob only wants the first two on his phone and
only the first on his watch or dashboard/inbox.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180425/ab584d31/attachment.html>