[openssl-commits] [openssl] master update

[kaduk]

The branch master has been updated
       via  272cc20b32915633402358e10ddc01fe43b8aebe (commit)
      from  48e5119a6b83fd5781174d3b524cb8d1dc411649 (commit)


- Log -----------------------------------------------------------------
commit 272cc20b32915633402358e10ddc01fe43b8aebe
Author: Benjamin Kaduk <bkaduk at akamai.com>
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 <rsalz at openssl.org>
    Reviewed-by: Andy Polyakov <appro at openssl.org>
    Reviewed-by: Paul Dale <paul.dale at oracle.com>
    (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