| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
because that's what OpenSSL 1.1 suggests. Even though that "unification"
doesn't really simplify anything but is more akin to repainting the bikeshed,
at least it doesn't cause any additional harm, so keeping recommendations
consistent may reduce the risk of code breaking in the future.
Provide an example of decryption with AES-CCM in addition to the
example of encryption already in place, because there are a number
of subtle and non-obvious differences that users have to pay
attention to.
Both ideas originally suggested by tb@.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I admit this is unusually long for a manual page. But that's not my fault
as a documentation author. An example in a manual page ought to be minimal
to show what needs to be demonstrated, and this example is minimal in that
sense. Making it shorter without loosing important aspects does not seem
possible.
When an API is poorly designed, one of the consequences is that that
documentation becomes harder to understand and often longer - in this
case to the point of becoming outright intimidating. If people dislike
that, they should design better APIs in the first place rather than
blasting the poor manual page for being too long or too complicated.
OK tb@
|
|
|
algorithm-independent EVP_EncryptInit(3) manual as another step
in making the latter leaner and more palatable.
As a side benefit, the new EVP_aes_128_ccm(3) manual page may provide
a better fighting chance to programmers who see themselves forced to
support CCM for whatever reason. It documents the mandatory, but so
far undocumented EVP_CTRL_CCM_GET_TAG control command and makes the
description of the three EVP_CTRL_CCM_SET_* control commands and the
numerous related quirks more precise.
|
