Add descriptions of AES-CCM, Camellia-CBC, and Chacha20.
Details
- Reviewers
cem - Group Reviewers
manpages - Commits
- rS361809: Update crypto(7) to list current ciphers.
This doesn't try to resolve the issues of better names for stream
ciphers. OpenSSL seems to advertise an effective block size of 1
for stream ciphers (and AES-XTS) FWIW, so using a block size of 1
might not be the worst way to describe this.
I probably want to refactor this a bit further in the future to
split into separate sections for AEAD, "plain" cipher, and hashes.
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
share/man/man7/crypto.7 | ||
---|---|---|
46–47 ↗ | (On Diff #72128) | Doh, I misread this as changing the .It Dv rather than the width at first. |
57 ↗ | (On Diff #72128) | If we're documenting that counter-mode ciphers require IVs (nonces?), maybe document that CBC needs a random IV here. |
71 ↗ | (On Diff #72128) | I think "implements" fits better here than "uses." The former sentence is already kind of awkward, so it might make sense to rewrite it to avoid "implements - implements" awkwardness too. |
75 ↗ | (On Diff #72128) | "read from or written to" is more English-ey. It reads more clearly to me in this instance. |
79 ↗ | (On Diff #72128) | "a unique nonce"? |
share/man/man7/crypto.7 | ||
---|---|---|
71 ↗ | (On Diff #72128) | What I'd really like to do is restructure the page as a followup I think into lists of algorithms by types, so a list of AEAD algorithms, a list of cipher algorithms, and a list of digest algorithms (we don't have any of those currently though). I think this also lets us consolidate some of the duplicate wording a bit and have the per-cipher entries only focus on the cipher-specific notes like key sizes, etc. |
79 ↗ | (On Diff #72128) | This (and the other bits for CCM) are also broken in the GCM description where it was copied from. I think what jmg@ was trying to say is that you have to specify an explicit IV in crp_iv rather than having it be part of the payload for these ciphers. Maybe I would just reword this to say that. All of the algorithms which use IVs require an IV for each call. I think OCF originally would assume CBC and cache the last block of the previous operation to use as the IV of the next, but when OCF was first imported into FreeBSD for IPsec I think that was discarded and in FreeBSD all the ciphers always need an IV for every call. |