Initialization vector requirements

[Falko Strenzke]

[re-sent to list]

Am 18.09.24 um 10:07 schrieb Falko Strenzke:
> Hi Werner,
>
> Am 13.09.24 um 14:40 schrieb Werner Koch:
>> Hi,
>>
>> and thanks for looking at the specs.
>>
>> On Tue, 10 Sep 2024 09:56, Falko Strenzke said:
>>
>>> says that "the initialization vector per message MUST be distinct" for
>>> OCB. Distinctness is not sufficient here, since the per-chunk nonce is
>>> derived by XORing the IV with the chunk index. Thus, for messages with
>> Right.  A simple fix might be to write
>>
>> "the initialization vector and thus derived nonces MUST be distinct per
>> message chunk"
> Yes, that is the effective requirement. But it leaves open how the 
> sender should know the nonces used in previous encryption processes 
> for the same key. That might actually be OK, since all this happens 
> under the premise of session key reuse, which is not the normal case 
> (as stated under 2.1. Confidentiality via Encryption 
> <https://www.ietf.org/archive/id/draft-koch-librepgp-02.html#name-confidentiality-via-encrypt>, 
> a new session key should be created for each message). Thus session 
> key reuse is a special case the exact circumstances of which must 
> remain open in the spec, and it seems valid to leave it to the 
> implementer how to achieve distinct nonces per chunk.
>>> Accordingly, random IVs are required here. After this correction, it
>> Well, that is the easiest solution and given that an RNG is anyway
>> required most likely that what everyone will do.
>>
>>> considerations regarding the number of repeated messages under the
>>> same key using random IVs and the resulting nonce-collision
>>> probabilities.
>> That is hard to describe because it depends on the size of the chunks
>> and the message.  In this regard a mimimal but large chunk size would be
>> better.  But we better don't open that issue again.
>
> Maybe it is also fine to leave the math to an implementer who want to 
> use session key reuse in the first place.
>
> Best regards,
> Falko
>
>> Salam-Shalom,
>>
>>     Werner
>>
> -- 
>
> *MTG AG*
> Dr. Falko Strenzke
>
> Phone: +49 6151 8000 24
> E-Mail: falko.strenzke at mtg.de
> Web: mtg.de <https://www.mtg.de>
>
> ------------------------------------------------------------------------
>
> MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
> Commercial register: HRB 8901
> Register Court: Amtsgericht Darmstadt
> Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
> Chairman of the Supervisory Board: Dr. Thomas Milde
>
> This email may contain confidential and/or privileged information. If 
> you are not the correct recipient or have received this email in error,
> please inform the sender immediately and delete this 
> email.Unauthorised copying or distribution of this email is not permitted.
>
> Data protection information: Privacy policy 
> <https://www.mtg.de/en/privacy-policy>
>
-- 

*MTG AG*
Dr. Falko Strenzke

Phone: +49 6151 8000 24
E-Mail: falko.strenzke at mtg.de
Web: mtg.de <https://www.mtg.de>

------------------------------------------------------------------------

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If 
you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email.Unauthorised 
copying or distribution of this email is not permitted.

Data protection information: Privacy policy 
<https://www.mtg.de/en/privacy-policy>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://librepgp.org/pipermail/librepgp-discuss/attachments/20240919/43e6bed2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5050 bytes
Desc: Kryptografische S/MIME-Signatur
URL: <https://librepgp.org/pipermail/librepgp-discuss/attachments/20240919/43e6bed2/attachment.bin>