diff options
author | Benjamin Kaduk <bkaduk@akamai.com> | 2018-01-09 15:26:37 -0600 |
---|---|---|
committer | Benjamin Kaduk <kaduk@mit.edu> | 2018-01-19 10:24:01 -0600 |
commit | 272cc20b32915633402358e10ddc01fe43b8aebe (patch) | |
tree | 0afe7a86e70f52029c9203dce4f5bc74971f1b68 /doc | |
parent | 48e5119a6b83fd5781174d3b524cb8d1dc411649 (diff) |
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@openssl.org>
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/5048)
Diffstat (limited to 'doc')
-rw-r--r-- | doc/man1/enc.pod | 18 |
1 files changed, 16 insertions, 2 deletions
diff --git a/doc/man1/enc.pod b/doc/man1/enc.pod index 2ec4d169b1..2a4497b5bd 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 |