<div dir="ltr"><div class="gmail_default" style="font-size:small">We have had PKCS#7, Cryptolopes and now JOSE for ages but none of them really does what I want when designing a protocol.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Traditional approaches for static data give me a key exchange that gives me as output:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Encryption algorithm</div><div class="gmail_default" style="font-size:small">Initialization vector</div><div class="gmail_default" style="font-size:small">Encryption key</div><div class="gmail_default" style="font-size:small">Authentication key (optional)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So my key agreement structure has the following information</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* The (default) bulk encryption/authentication algorithms and modes</div><div class="gmail_default" style="font-size:small">* For each recipient key</div><div class="gmail_default" style="font-size:small">    * Recipient key identifier</div><div class="gmail_default" style="font-size:small">    * Encrypted key exchange data</div><div class="gmail_default" style="font-size:small">    * Wrapped key [if a key agreement is used]</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The wrapped key is the master secret.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Note that the IV is NOT part of this data. This is instead prepended to the encrypted data chunk as follows:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">

<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">[Length] [Header]</span>

<br></div><div class="gmail_default" style="font-size:small">[Length] [Salt]</div><div class="gmail_default" style="font-size:small">([Length'] [Non-terminal data chunk]) *</div><div class="gmail_default" style="font-size:small">

<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">[Length] [Terminal data chunk]</span>

<br></div><div class="gmail_default" style="font-size:small">

<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial;background-color:rgb(255,255,255);float:none;display:inline">[Length] [Trailer] </span><br></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span><br></span></span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span>The tagging scheme allows terminal and non terminal chunks to be distinguished. The trailer is only present if required by the bulk algorithm.</span></span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span><br></span></span></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Alternatively the Header may be used to specify a key identifier for the exchange. </div><div class="gmail_default" style="font-size:small"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span><br></span></span></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The IV and key(s) for the bulk encryption/authentication algorithm are calculated from the master secret using the specified salt.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The structure of the salt is opaque to the encryption format but MAY be constructed from:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* A counter. This provides a means of recovering order from a sequence of encrypted packets without additional data.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* 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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* A counter plus a random value.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* 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.</div><div class="gmail_default" style="font-size:small"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span><br></span></span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span><br></span></span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span>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).</span></span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span><br></span></span></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The consequences of this approach are as follows:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Pro: </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* Multiple blocks of data are automatically encrypted under separate IVs and Keys</div><div class="gmail_default" style="font-size:small">* Supports all the functionality of PKCS#7 / JOSE </div><div class="gmail_default" style="font-size:small">* Single processing path regardless of encryption options</div><div class="gmail_default" style="font-size:small">* Straightforward format with no unnecessary hierarchy</div><div class="gmail_default" style="font-size:small">* The encryptor has no direct control over the encryption key used.</div><div class="gmail_default" style="font-size:small">* Supports embedded/detached key exchange modes and allows one to be converted to the other.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Con:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* It is not possible to exchange previously encrypted data using this format unless an option is provided to support an additional key wrap.</div><div class="gmail_default" style="font-size:small">* The use of key wrap in the DH/ECDH exchange provides a subliminal channel for the encryptor.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"></div></div>