The branch master has been updated
via 272cc20b32915633402358e10ddc01fe43b8aebe (commit)
from 48e5119a6b83fd5781174d3b524cb8d1dc411649 (commit)
- Log -----------------------------------------------------------------
commit 272cc20b32915633402358e10ddc01fe43b8aebe
Author: Benjamin Kaduk <[email protected]>
Date: Tue Jan 9 15:26:37 2018 -0600
enc(1): document that AEAD is not and will not be supported
Note the reasons, including streaming output issues and key/iv/nonce
management issues.
Recommend the use of cms(1) instead.
Fixes #471.
Reviewed-by: Rich Salz <[email protected]>
Reviewed-by: Andy Polyakov <[email protected]>
Reviewed-by: Paul Dale <[email protected]>
(Merged from https://github.com/openssl/openssl/pull/5048)
-----------------------------------------------------------------------
Summary of changes:
doc/man1/enc.pod | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/doc/man1/enc.pod b/doc/man1/enc.pod
index 2ec4d16..2a4497b 100644
--- a/doc/man1/enc.pod
+++ b/doc/man1/enc.pod
@@ -243,8 +243,22 @@ list of ciphers, supported by your version of OpenSSL,
including
ones provided by configured engines.
The B<enc> program does not support authenticated encryption modes
-like CCM and GCM. The utility does not store or retrieve the
-authentication tag.
+like CCM and GCM, and will not support such modes in the future.
+The B<enc> interface by necessity must begin streaming output (e.g.,
+to standard output when B<-out> is not used before the authentication
+tag could be validated, leading to the usage of B<enc> in pipelines
+that begin processing untrusted data and are not capable of rolling
+back upon authentication failure. The AEAD modes currently in common
+use also suffer from catastrophic failure of confidentiality and/or
+integrity upon reuse of key/iv/nonce, and since B<enc> places the
+entire burden of key/iv/nonce management upon the user, the risk of
+exposing AEAD modes is too great to allow. These key/iv/nonce
+management issues also affect other modes currently exposed in B<enc>,
+but the failure modes are less extreme in these cases, and the
+functionality cannot be removed with a stable release branch.
+For bulk encryption of data, whether using authenticated encryption
+modes or other modes, L<cms(1)> is recommended, as it provides a
+standard data format and performs the needed key/iv/nonce management.
base64 Base 64
_____
openssl-commits mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-commits
