Mailing List Archive

EFail mitigations for S/MIME (was: efail -> improvements in case w/o AE (e.g. CMS))
Hi,

It think Bernhards mail can be summed up further. To check that the encrypted
data was not manipulated we only need:

- Any hash over the plaintext.

To get such a hash we can most easily use a signature, regardless of any trust
in the signature. The hash does not need to be encrypted.

If we have no hash we won't offer to save a decrypted file from a GUI or show
it in an HTML enabled mail client. This would disallow encrypt, then sign
schemes but in practice everyone uses sign then encrypt anyway.

Best regards,
Andre

--
Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
Re: EFail mitigations for S/MIME [ In reply to ]
On Tue, 15 May 2018 14:31, aheinecke@intevation.de said:

> - Any hash over the plaintext.

You mean to put a hash as kind of additional data inside the
EnvelopedData (the CMS name for encrypted dats) to make somthing like
the OpenPGP MDC?

CMS does not allow for this. What you can do is to put arbitrary
attributes into the UnprotectedAttributes section. But as the name
says, this is unprotected and not encrypted so it differs from an MDC.

Anyway, this would be a proprietary extension which does not help with
interoperability. If you don't need to be interoperabe with other
S/MIME implementaion it is anyway better to use OpenPGP. I would bet
that many implementations will bail out on that uncommon and optional
UnprotectedAttributes.

CMS has the AuthenticatedData as a MAC system which could be put around
the EnvelopedData but this features is not implemented in any widely
used client. The actual extension for authenticated data is RFC-5083
which describes the Authenticated-Enveloped-Data content type. It can
be used with AES-CCM or AES-GCM as specified in RFC-5084 (urgs) or with
ChaCHa20-poly1305 (RFC-8103). But well, it is also not implemented.

If you want to fix CMS this should be used - iff all vendors agree.


Shalom-Salam,

Werner

--
# Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken
sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: EFail mitigations for S/MIME [ In reply to ]
On Wed, 16 May 2018 13:32, wk@gnupg.org said:

> be used with AES-CCM or AES-GCM as specified in RFC-5084 (urgs) or with
> ChaCHa20-poly1305 (RFC-8103). But well, it is also not implemented.

I forgot RFC-6476 which uses a MAC instead of a counter based algorithm
and thus would be more robust.


Shalom-Salam,

Werner


--
# Please read: Daniel Ellsberg - The Doomsday Machine #
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: EFail mitigations for S/MIME [ In reply to ]
Hi,

On Wednesday, May 16, 2018 1:32:00 PM CEST Werner Koch wrote:
> On Tue, 15 May 2018 14:31, aheinecke@intevation.de said:
>
> > - Any hash over the plaintext.
>
> You mean to put a hash as kind of additional data inside the
> EnvelopedData (the CMS name for encrypted dats) to make somthing like
> the OpenPGP MDC?
>
> CMS does not allow for this. What you can do is to put arbitrary
> attributes into the UnprotectedAttributes section. But as the name
> says, this is unprotected and not encrypted so it differs from an MDC.

Not really. I also don't think that it needs to be encrypted.

Basically: Alice sends Bob encrypted data and also sends Bob "This is the hash
of the plaintext" by signing the plaintext.

Then Bobs client can know "This plaintext matches the hash Alice told me
about". -> It has not been manipulated.
Even if Eve can manipulate the Hash that Alice sends to Bob she can't create a
valid Hash for the original plaintext + her modifications.

> Anyway, this would be a proprietary extension which does not help with
> interoperability. If you don't need to be interoperabe with other
> S/MIME implementaion it is anyway better to use OpenPGP. I would bet
> that many implementations will bail out on that uncommon and optional
> UnprotectedAttributes.

No extension. Basically what I want to do is that for S/MIME HTML Mail / Mails
with attachments GpgOL will only put the plaintext into Outlook if it also has
a valid signature. Regardless of the trust in the signature.

I know it's a hack and proper AE would be better but I think it would mitigate
an EFail style modification attack.


Best Regards,
Andre
--
Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
Re: EFail mitigations for S/MIME [ In reply to ]
On 15-05-18 14:31, Andre Heinecke wrote:
> Hi,
>
> It think Bernhards mail can be summed up further. To check that the encrypted
> data was not manipulated we only need:
>
> - Any hash over the plaintext.
>
> To get such a hash we can most easily use a signature, regardless of any trust
> in the signature. The hash does not need to be encrypted.
>
> If we have no hash we won't offer to save a decrypted file from a GUI or show
> it in an HTML enabled mail client. This would disallow encrypt, then sign
> schemes but in practice everyone uses sign then encrypt anyway.

Adding a hash will not help in the general case because other S/MIME
clients will not support it.

I have done some experiments with the "Generic exfiltration" attack and
have been able to replicate the attack. Injecting new blocks is easy.
However after every injected block, there is a block of random data.
This block of random data can be used to detect whether the message was
attacked with EFAIL in most cases. The S/MIME RFCs strongly suggest that
every MIME part should be 7-bit. If a decrypted message therefore
contains data > 127 or < 32 excluding CR/LF/TAB, the message might have
been injected with additional blocks. For the "Generic exfiltration"
EFAIL attack, you need at least 2 blocks of data so there will be at
least 32 bytes of random data. The changes that all those bytes fall
within the 7-bit range is slim so I think this check would work to
detect most (if not all) EFAIL attacks. The only problem you might run
into is if a sender encrypted a message containing 8-bit characters
(i.e., the message was not canonicalized to 7-bit).

I have written a short blog item about this here

https://www.ciphermail.com/blog/efail-how-to-detect-you-are-being-attacked.html

Any comments on whether this will work?

As we speak I'm working on such a check.

Kind regards,

Martijn Brinkers


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: EFail mitigations for S/MIME [ In reply to ]
On Wed, 16 May 2018 14:09, aheinecke@intevation.de said:

> No extension. Basically what I want to do is that for S/MIME HTML Mail / Mails
> with attachments GpgOL will only put the plaintext into Outlook if it also has
> a valid signature. Regardless of the trust in the signature.

You need to have the key for the signature and all kind of online
checking of the key - remember it is X.509 and thus subject to malicious
certifciates. We all know from OpenPGP that getting the key for signed
message is not easy if people don't upload to a keyserver. For S?MIME
it is worse. Without a key you can't check the signature.

There are legitimate reasons not to sign a mail and to let the recipient
decide, based on the content, whether it has been received from the
expected sender. For example in a VS-NfD setting signatures are
simply out of scope and thus not used.


Shalom-Salam,

Werner

--
# Please read: Daniel Ellsberg - The Doomsday Machine #
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: EFail mitigations for S/MIME [ In reply to ]
On 2018-05-16 at 14:09 +0200, Andre Heinecke wrote:
> Not really. I also don't think that it needs to be encrypted.
>
> Basically: Alice sends Bob encrypted data and also sends Bob "This is
> the hash of the plaintext" by signing the plaintext.
>
> Then Bobs client can know "This plaintext matches the hash Alice told
> me about". -> It has not been manipulated.
> Even if Eve can manipulate the Hash that Alice sends to Bob she can't
> create a valid Hash for the original plaintext + her modifications.

At first sight, it looks enough, since it would require already knowing
the plaintext. However, it is not. You are providing an oracle that
allows confirming whether a content is the one suspected by the
attacker.

Suppose we are in the context of a poll, where Alice sent Bob "The
president should be Charlie". At the end of the vote, Bob publishes the
encrypted mails, for auditing reasons.
Eve wants to know for whom did Alice vote, so she -suspecting she voted
for Charlie-, extracts the encrypted content, adds her own hash for the
guessed plaintext, and sends it to the victim (she can perform any
cipher malleability attack by simply adjusting the final hash).
If the content is decrypted, it means she guessed right. Otherwise, the
encrypted contents were different, the decryption failed and she will
try the attack again with another candidate. (She may even be able to
test several guesses in a single malicious email)

You need both pieces to be linked. It could be enough to just include in
the hash computation a "secret IV" that is stored in the encrypted part,
but it seems fragile, and at that point, I would simply include the hash
itself.


(Obviously, if you were really including a cleartext-signed hash of the
message, Eve wouldn't need to perform an efail attack at all, as she
could simply test the hash against the list of people running for
president)


Best regards


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: EFail mitigations for S/MIME [ In reply to ]
IMHO the correct solution would be to switch to a true Authenticated Encryption mode - like AES-OCB or AES-GCM.

Is there a chance to have this implemented soon?

Sent from my test iPhone

> On May 16, 2018, at 12:34, Ángel <angel@pgp.16bits.net> wrote:
>
>> On 2018-05-16 at 14:09 +0200, Andre Heinecke wrote:
>> Not really. I also don't think that it needs to be encrypted.
>>
>> Basically: Alice sends Bob encrypted data and also sends Bob "This is
>> the hash of the plaintext" by signing the plaintext.
>>
>> Then Bobs client can know "This plaintext matches the hash Alice told
>> me about". -> It has not been manipulated.
>> Even if Eve can manipulate the Hash that Alice sends to Bob she can't
>> create a valid Hash for the original plaintext + her modifications.
>
> At first sight, it looks enough, since it would require already knowing
> the plaintext. However, it is not. You are providing an oracle that
> allows confirming whether a content is the one suspected by the
> attacker.
>
> Suppose we are in the context of a poll, where Alice sent Bob "The
> president should be Charlie". At the end of the vote, Bob publishes the
> encrypted mails, for auditing reasons.
> Eve wants to know for whom did Alice vote, so she -suspecting she voted
> for Charlie-, extracts the encrypted content, adds her own hash for the
> guessed plaintext, and sends it to the victim (she can perform any
> cipher malleability attack by simply adjusting the final hash).
> If the content is decrypted, it means she guessed right. Otherwise, the
> encrypted contents were different, the decryption failed and she will
> try the attack again with another candidate. (She may even be able to
> test several guesses in a single malicious email)
>
> You need both pieces to be linked. It could be enough to just include in
> the hash computation a "secret IV" that is stored in the encrypted part,
> but it seems fragile, and at that point, I would simply include the hash
> itself.
>
>
> (Obviously, if you were really including a cleartext-signed hash of the
> message, Eve wouldn't need to perform an efail attack at all, as she
> could simply test the hash against the list of people running for
> president)
>
>
> Best regards
>
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: EFail mitigations for S/MIME [ In reply to ]
> IMHO the correct solution would be to switch to a true Authenticated
> Encryption mode - like AES-OCB or AES-GCM.

Tell it to the Working Group, please. We don't get to write the RFC by
ourselves.

> Is there a chance to have this implemented soon?

No. Get the WG to define it and GnuPG will implement it.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: EFail mitigations for S/MIME [ In reply to ]
On 05/17/2018 01:00 AM, Uri Blumenthal wrote:
> IMHO the correct solution would be to switch to a true Authenticated Encryption mode - like AES-OCB or AES-GCM.
>
> Is there a chance to have this implemented soon?

AFAIU the attack put forward by Ángel doesn't work against GnuPG's MDC.

That said, the move to a true AE mode is coming with the next standard,
and will I guess be implemented when the standard will be finalized enough.

>> On May 16, 2018, at 12:34, Ángel <angel@pgp.16bits.net> wrote:
>>
>>> On 2018-05-16 at 14:09 +0200, Andre Heinecke wrote:
>>> Not really. I also don't think that it needs to be encrypted.
>>>
>>> Basically: Alice sends Bob encrypted data and also sends Bob "This is
>>> the hash of the plaintext" by signing the plaintext.
>>>
>>> Then Bobs client can know "This plaintext matches the hash Alice told
>>> me about". -> It has not been manipulated.
>>> Even if Eve can manipulate the Hash that Alice sends to Bob she can't
>>> create a valid Hash for the original plaintext + her modifications.
>>
>> At first sight, it looks enough, since it would require already knowing
>> the plaintext. However, it is not. You are providing an oracle that
>> allows confirming whether a content is the one suspected by the
>> attacker.
>>
>> Suppose we are in the context of a poll, where Alice sent Bob "The
>> president should be Charlie". At the end of the vote, Bob publishes the
>> encrypted mails, for auditing reasons.
>> Eve wants to know for whom did Alice vote, so she -suspecting she voted
>> for Charlie-, extracts the encrypted content, adds her own hash for the
>> guessed plaintext, and sends it to the victim (she can perform any
>> cipher malleability attack by simply adjusting the final hash).
>> If the content is decrypted, it means she guessed right. Otherwise, the
>> encrypted contents were different, the decryption failed and she will
>> try the attack again with another candidate. (She may even be able to
>> test several guesses in a single malicious email)
>>
>> You need both pieces to be linked. It could be enough to just include in
>> the hash computation a "secret IV" that is stored in the encrypted part,
>> but it seems fragile, and at that point, I would simply include the hash
>> itself.
>>
>>
>> (Obviously, if you were really including a cleartext-signed hash of the
>> message, Eve wouldn't need to perform an efail attack at all, as she
>> could simply test the hash against the list of people running for
>> president)
>>
>>
>> Best regards
>>
>>
>> _______________________________________________
>> Gnupg-devel mailing list
>> Gnupg-devel@gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: EFail mitigations for S/MIME [ In reply to ]
Hi,

On Wednesday, May 16, 2018 4:15:45 PM CEST martijn.list wrote:
> On 15-05-18 14:31, Andre Heinecke wrote:
> > - Any hash over the plaintext.
> >
> > To get such a hash we can most easily use a signature, regardless of any
trust
> > in the signature. The hash does not need to be encrypted.
> >
> > If we have no hash we won't offer to save a decrypted file from a GUI or
show
> > it in an HTML enabled mail client. This would disallow encrypt, then sign
> > schemes but in practice everyone uses sign then encrypt anyway.
>
> Adding a hash will not help in the general case because other S/MIME
> clients will not support it.

I don't propose to extend the standard. I would only reuse the the hash of a
multipart/signed part in an S/MIME mail or from a signature in the case of
files.

> I have done some experiments with the "Generic exfiltration" attack and
> have been able to replicate the attack. Injecting new blocks is easy.
> However after every injected block, there is a block of random data.
> This block of random data can be used to detect whether the message was
> attacked with EFAIL in most cases. The S/MIME RFCs strongly suggest that
> every MIME part should be 7-bit. If a decrypted message therefore
> contains data > 127 or < 32 excluding CR/LF/TAB, the message might have
> been injected with additional blocks. For the "Generic exfiltration"
> EFAIL attack, you need at least 2 blocks of data so there will be at
> least 32 bytes of random data. The changes that all those bytes fall
> within the 7-bit range is slim so I think this check would work to
> detect most (if not all) EFAIL attacks. The only problem you might run
> into is if a sender encrypted a message containing 8-bit characters
> (i.e., the message was not canonicalized to 7-bit).
>
> I have written a short blog item about this here
>
> https://www.ciphermail.com/blog/efail-how-to-detect-you-are-being-attacked.html
>
> Any comments on whether this will work?

From your blog it sounds like this is only specified for multipart/signed
inside the encrypted part. If it is signed can't you just check the signature
and only show the signed parts?

Also for Gpg4win I'm thinking a bit about files. We offer through Kleopatra CMS
file encryption, which would have similar problems :-/ .


Best Regards,
Andre

--
Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
Re: EFail mitigations for S/MIME [ In reply to ]
Hi,

On Wednesday, May 16, 2018 5:30:47 PM CEST ?ngel wrote:
> On 2018-05-16 at 14:09 +0200, Andre Heinecke wrote:
> > Not really. I also don't think that it needs to be encrypted.
> >
> > Basically: Alice sends Bob encrypted data and also sends Bob "This is
> > the hash of the plaintext" by signing the plaintext.
> >
> > Then Bobs client can know "This plaintext matches the hash Alice told
> > me about". -> It has not been manipulated.
> > Even if Eve can manipulate the Hash that Alice sends to Bob she can't
> > create a valid Hash for the original plaintext + her modifications.
>
> At first sight, it looks enough, since it would require already knowing
> the plaintext. However, it is not. You are providing an oracle that
> allows confirming whether a content is the one suspected by the
> attacker.

For the usual S/MIME mail case I would say that this is mostly mitigated
because the hash is encrypted in that case. As the only case we would accept
for mail would be sign then encrypt and would only show the signed parts.

But in general you are right about the problems of an unencrypted hash as I
have proposed / suggested it and thank you for pointing it out.

I still think that the situation might be improved if we would strongly
suggest / force users to provide signatures for CMS encrypted files, too. This
should be done anyway, especially for active content like HTML or a binary.

On the other hand the situation with this is not really changed with EFail. If
you handle unsigned files you can't trust the file by cryptography alone. And we
already warn when we handle unsigned content in Kleopatra.

So we might only enforce this for active content in mails for Outlook.

> Suppose we are in the context of a poll, where Alice sent Bob "The
> president should be Charlie". At the end of the vote, Bob publishes the
> encrypted mails, for auditing reasons.
> Eve wants to know for whom did Alice vote, so she -suspecting she voted
> for Charlie-, extracts the encrypted content, adds her own hash for the
> guessed plaintext, and sends it to the victim (she can perform any
> cipher malleability attack by simply adjusting the final hash).
> If the content is decrypted, it means she guessed right. Otherwise, the
> encrypted contents were different, the decryption failed and she will
> try the attack again with another candidate. (She may even be able to
> test several guesses in a single malicious email)
>
> You need both pieces to be linked. It could be enough to just include in
> the hash computation a "secret IV" that is stored in the encrypted part,
> but it seems fragile, and at that point, I would simply include the hash
> itself.
>
>
> (Obviously, if you were really including a cleartext-signed hash of the
> message, Eve wouldn't need to perform an efail attack at all, as she
> could simply test the hash against the list of people running for
> president)

I agree with you and all others here that proper AE would be much much better.
I'm just thinking about a quick solution to improve the situation for Gpg4win
users without relying on any support from other clients.


Best Regards,
Andre

--
Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
Re: EFail mitigations for S/MIME [ In reply to ]
Am Donnerstag 17 Mai 2018 02:40:58 schrieb Robert J. Hansen:
> > IMHO the correct solution would be to switch to a true Authenticated
> > Encryption mode - like AES-OCB or AES-GCM.
>
> Tell it to the Working Group, please. ?We don't get to write the RFC by
> ourselves.

As Werner pointed out:
There is already RFC6476 which uses the SMIMECapabilities attribute
as defined in STD 70 (aka rfc5751) to define a "Message Authentication Code
(MAC) Encryption in the Cryptographic Message Syntax (CMS)"
and there is RFC8103 providing another one.

So we would need to get S/MIME application vendors to implement one of these.

Best,
Bernhard

--
www.intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
Re: EFail mitigations for S/MIME [ In reply to ]
On 17-05-18 08:10, Andre Heinecke wrote:
> Hi,
>
> On Wednesday, May 16, 2018 4:15:45 PM CEST martijn.list wrote:
>> On 15-05-18 14:31, Andre Heinecke wrote:
>>> - Any hash over the plaintext.
>>>
>>> To get such a hash we can most easily use a signature, regardless of any
> trust
>>> in the signature. The hash does not need to be encrypted.
>>>
>>> If we have no hash we won't offer to save a decrypted file from a GUI or
> show
>>> it in an HTML enabled mail client. This would disallow encrypt, then sign
>>> schemes but in practice everyone uses sign then encrypt anyway.
>>
>> Adding a hash will not help in the general case because other S/MIME
>> clients will not support it.
>
> I don't propose to extend the standard. I would only reuse the the hash of a
> multipart/signed part in an S/MIME mail or from a signature in the case of
> files.
>
>> I have done some experiments with the "Generic exfiltration" attack and
>> have been able to replicate the attack. Injecting new blocks is easy.
>> However after every injected block, there is a block of random data.
>> This block of random data can be used to detect whether the message was
>> attacked with EFAIL in most cases. The S/MIME RFCs strongly suggest that
>> every MIME part should be 7-bit. If a decrypted message therefore
>> contains data > 127 or < 32 excluding CR/LF/TAB, the message might have
>> been injected with additional blocks. For the "Generic exfiltration"
>> EFAIL attack, you need at least 2 blocks of data so there will be at
>> least 32 bytes of random data. The changes that all those bytes fall
>> within the 7-bit range is slim so I think this check would work to
>> detect most (if not all) EFAIL attacks. The only problem you might run
>> into is if a sender encrypted a message containing 8-bit characters
>> (i.e., the message was not canonicalized to 7-bit).
>>
>> I have written a short blog item about this here
>>
>> https://www.ciphermail.com/blog/efail-how-to-detect-you-are-being-attacked.html
>>
>> Any comments on whether this will work?
>
> From your blog it sounds like this is only specified for multipart/signed
> inside the encrypted part. If it is signed can't you just check the signature
> and only show the signed parts?

No it works for general content types. The multipart/signed content type
was only used for the example.

You can modify a block (16 bytes in case of AES128) without introducing
a random block. Inserting a new block however will introduce a random
block after the inserted block. For an attack you need at least two
blocks (probably a lot more) so there is plenty of random data in the
decrypted mime.

Because the attacker can modify the decrypted MIME, it is possible to
remove the multipart/signed content type. For example by adding a number
of newlines. The final decrypted message is therefore no longer a signed
message so checking the signature will not work in the general case.

Kind regards,

Martijn Brinkers


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: EFail mitigations for S/MIME [ In reply to ]
On Thu, 17 May 2018 02:40, rjh@sixdemonbag.org said:
> Tell it to the Working Group, please. We don't get to write the RFC by
> ourselves.

No need to tell it the working group. AuthEnvelopedData is specified
since 2007 along with at least 3 other RFCs with the detailed
specification of the algorithm:

- RFC-5083 specifies the new content type
- RFC-5084 specifies its use with AES-CCM and AES-GCM
- RFC-6476 specifies its use with a MAC
- RFC-8103 specifies its use with ChaCha20-Poly1305

Because CMS has no reliable working preference system, the real
challenge is to get all major nendors to agree on one or two algorithms
and and implement them. Due to the brittleness of all counter modes I
would go with a MAC.

Uri: Do you know an RFC specifying the use with OCB?



Salam-Shalom,

Werner

--
# Please read: Daniel Ellsberg - The Doomsday Machine #
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.