Hi
-04 is about to expire. These will be the changes in -05:
--8<---------------cut here---------------start------------->8---
** New key flag:
# The second octet:
+ 0x04 - This key may be used as an additional decryption subkey (ADSK).
# The idea is that implementations will also encrypt to a second subkey
# which for example is used on a second device. I am not sure whether
# this is suitable solution and makes much sense so this is intended as a
# bait for discussion.
** Deprecation of Symmetrically Encrypted Data Packet
+ This packet is obsolete. An implementation MUST not create this
+ packet. An implementation MAY process such a packet but it MUST
+ return a clear diagnostic that a non-integrity protected packet has
+ been processed. The implementation SHOULD also return an error in
+ this case and stop processing.
** Limit the chunk size of AEAD packets:
An implementation MUST support chunk size octets with values from 0 to
56. Chunk size octets with other values are reserved for future
+ extensions. Implementations SHOULD NOT create data with a chunk size
+ octet value larger than 21 (128 MiB chunks) to facilitate buffering of
+ not yet authenticated plaintext.
** Explict warning reading the AEAD IV:
A new random initialization vector MUST be used for each message.
+ Failure to do so for each message will lead to a catastrophic failure
+ depending on the used AEAD mode.
** More pressure to use AEAD:
- This attack can be defeated by the use of Modification Detection,
+ This attack can be defeated by the use of modification detection,
provided that the implementation does not let the user naively
- return the data to the attacker. An implementation MUST treat an MDC
- failure as a security problem, not merely a data problem.
-
- In either case, the implementation MAY allow the user access to the
- erroneous data, but MUST warn the user as to potential security
- problems should that data be returned to the sender.
+ return the data to the attacker. The modification detection is
+ prefereabble implemented by using the AEAD Encrypted Data Packet
+ and only if the recipients don't supports this by use of the
+ Symmmetric Encrypted and Integrity Protected Data Packet. An
+ implementation MUST treat an authentication or MDC failure as a
+ security problem, not merely a data problem.
+
+ In either case, the implementation SHOULD NOT allow the user
+ access to the erroneous data, and MUST warn the user as to
+ potential security problems should that data be returned to the
+ sender.
and changed the following suggestion to read
permits someone to trick a user to decrypt a message. Consequently,
it is important that:
1. Implementers treat authentication errors, MDC errors,
decompression failures or no use of MDC or AEAD as security
problems.
2. Implementers implement AEAD with all due speed and encourage
its spread.
3. Users migrate to implementations that support AEAD
encryption with all due speed.
** Clarify / cleanup OCB section, add EAX and OCB test vectors
--8<---------------cut here---------------end--------------->8---
See also git(_at_)gitlab(_dot_)com/openpgp-wg/rfc4880bis
Shalom-Salam,
Werner
--
# Please read: Daniel Ellsberg - The Doomsday Machine #
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
pgppJQUQqKZz2.pgp
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp