30 Dec, 2018

1 commit

  • Pull Kconfig updates from Masahiro Yamada:

    - support -y option for merge_config.sh to avoid downgrading =y to =m

    - remove S_OTHER symbol type, and touch include/config/*.h files correctly

    - fix file name and line number in lexer warnings

    - fix memory leak when EOF is encountered in quotation

    - resolve all shift/reduce conflicts of the parser

    - warn no new line at end of file

    - make 'source' statement more strict to take only string literal

    - rewrite the lexer and remove the keyword lookup table

    - convert to SPDX License Identifier

    - compile C files independently instead of including them from zconf.y

    - fix various warnings of gconfig

    - misc cleanups

    * tag 'kconfig-v4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (39 commits)
    kconfig: surround dbg_sym_flags with #ifdef DEBUG to fix gconf warning
    kconfig: split images.c out of qconf.cc/gconf.c to fix gconf warnings
    kconfig: add static qualifiers to fix gconf warnings
    kconfig: split the lexer out of zconf.y
    kconfig: split some C files out of zconf.y
    kconfig: convert to SPDX License Identifier
    kconfig: remove keyword lookup table entirely
    kconfig: update current_pos in the second lexer
    kconfig: switch to ASSIGN_VAL state in the second lexer
    kconfig: stop associating kconf_id with yylval
    kconfig: refactor end token rules
    kconfig: stop supporting '.' and '/' in unquoted words
    treewide: surround Kconfig file paths with double quotes
    microblaze: surround string default in Kconfig with double quotes
    kconfig: use T_WORD instead of T_VARIABLE for variables
    kconfig: use specific tokens instead of T_ASSIGN for assignments
    kconfig: refactor scanning and parsing "option" properties
    kconfig: use distinct tokens for type and default properties
    kconfig: remove redundant token defines
    kconfig: rename depends_list to comment_option_list
    ...

    Linus Torvalds
     

28 Dec, 2018

1 commit

  • Pull crypto updates from Herbert Xu:
    "API:
    - Add 1472-byte test to tcrypt for IPsec
    - Reintroduced crypto stats interface with numerous changes
    - Support incremental algorithm dumps

    Algorithms:
    - Add xchacha12/20
    - Add nhpoly1305
    - Add adiantum
    - Add streebog hash
    - Mark cts(cbc(aes)) as FIPS allowed

    Drivers:
    - Improve performance of arm64/chacha20
    - Improve performance of x86/chacha20
    - Add NEON-accelerated nhpoly1305
    - Add SSE2 accelerated nhpoly1305
    - Add AVX2 accelerated nhpoly1305
    - Add support for 192/256-bit keys in gcmaes AVX
    - Add SG support in gcmaes AVX
    - ESN for inline IPsec tx in chcr
    - Add support for CryptoCell 703 in ccree
    - Add support for CryptoCell 713 in ccree
    - Add SM4 support in ccree
    - Add SM3 support in ccree
    - Add support for chacha20 in caam/qi2
    - Add support for chacha20 + poly1305 in caam/jr
    - Add support for chacha20 + poly1305 in caam/qi2
    - Add AEAD cipher support in cavium/nitrox"

    * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (130 commits)
    crypto: skcipher - remove remnants of internal IV generators
    crypto: cavium/nitrox - Fix build with !CONFIG_DEBUG_FS
    crypto: salsa20-generic - don't unnecessarily use atomic walk
    crypto: skcipher - add might_sleep() to skcipher_walk_virt()
    crypto: x86/chacha - avoid sleeping under kernel_fpu_begin()
    crypto: cavium/nitrox - Added AEAD cipher support
    crypto: mxc-scc - fix build warnings on ARM64
    crypto: api - document missing stats member
    crypto: user - remove unused dump functions
    crypto: chelsio - Fix wrong error counter increments
    crypto: chelsio - Reset counters on cxgb4 Detach
    crypto: chelsio - Handle PCI shutdown event
    crypto: chelsio - cleanup:send addr as value in function argument
    crypto: chelsio - Use same value for both channel in single WR
    crypto: chelsio - Swap location of AAD and IV sent in WR
    crypto: chelsio - remove set but not used variable 'kctx_len'
    crypto: ux500 - Use proper enum in hash_set_dma_transfer
    crypto: ux500 - Use proper enum in cryp_set_dma_transfer
    crypto: aesni - Add scatter/gather avx stubs, and use them in C
    crypto: aesni - Introduce partial block macro
    ..

    Linus Torvalds
     

27 Dec, 2018

1 commit

  • Pull RCU updates from Ingo Molnar:
    "The biggest RCU changes in this cycle were:

    - Convert RCU's BUG_ON() and similar calls to WARN_ON() and similar.

    - Replace calls of RCU-bh and RCU-sched update-side functions to
    their vanilla RCU counterparts. This series is a step towards
    complete removal of the RCU-bh and RCU-sched update-side functions.

    ( Note that some of these conversions are going upstream via their
    respective maintainers. )

    - Documentation updates, including a number of flavor-consolidation
    updates from Joel Fernandes.

    - Miscellaneous fixes.

    - Automate generation of the initrd filesystem used for rcutorture
    testing.

    - Convert spin_is_locked() assertions to instead use lockdep.

    ( Note that some of these conversions are going upstream via their
    respective maintainers. )

    - SRCU updates, especially including a fix from Dennis Krein for a
    bag-on-head-class bug.

    - RCU torture-test updates"

    * 'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (112 commits)
    rcutorture: Don't do busted forward-progress testing
    rcutorture: Use 100ms buckets for forward-progress callback histograms
    rcutorture: Recover from OOM during forward-progress tests
    rcutorture: Print forward-progress test age upon failure
    rcutorture: Print time since GP end upon forward-progress failure
    rcutorture: Print histogram of CB invocation at OOM time
    rcutorture: Print GP age upon forward-progress failure
    rcu: Print per-CPU callback counts for forward-progress failures
    rcu: Account for nocb-CPU callback counts in RCU CPU stall warnings
    rcutorture: Dump grace-period diagnostics upon forward-progress OOM
    rcutorture: Prepare for asynchronous access to rcu_fwd_startat
    torture: Remove unnecessary "ret" variables
    rcutorture: Affinity forward-progress test to avoid housekeeping CPUs
    rcutorture: Break up too-long rcu_torture_fwd_prog() function
    rcutorture: Remove cbflood facility
    torture: Bring any extra CPUs online during kernel startup
    rcutorture: Add call_rcu() flooding forward-progress tests
    rcutorture/formal: Replace synchronize_sched() with synchronize_rcu()
    tools/kernel.h: Replace synchronize_sched() with synchronize_rcu()
    net/decnet: Replace rcu_barrier_bh() with rcu_barrier()
    ...

    Linus Torvalds
     

23 Dec, 2018

4 commits

  • Remove dead code related to internal IV generators, which are no longer
    used since they've been replaced with the "seqiv" and "echainiv"
    templates. The removed code includes:

    - The "givcipher" (GIVCIPHER) algorithm type. No algorithms are
    registered with this type anymore, so it's unneeded.

    - The "const char *geniv" member of aead_alg, ablkcipher_alg, and
    blkcipher_alg. A few algorithms still set this, but it isn't used
    anymore except to show via /proc/crypto and CRYPTO_MSG_GETALG.
    Just hardcode "" or "" in those cases.

    - The 'skcipher_givcrypt_request' structure, which is never used.

    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     
  • salsa20-generic doesn't use SIMD instructions or otherwise disable
    preemption, so passing atomic=true to skcipher_walk_virt() is
    unnecessary.

    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     
  • skcipher_walk_virt() can still sleep even with atomic=true, since that
    only affects the later calls to skcipher_walk_done(). But,
    skcipher_walk_virt() only has to allocate memory for some input data
    layouts, so incorrectly calling it with preemption disabled can go
    undetected. Use might_sleep() so that it's detected reliably.

    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     
  • This patch removes unused dump functions for crypto_user_stats.
    There are remains of the copy/paste of crypto_user_base to
    crypto_user_stat and I forgot to remove them.

    Signed-off-by: Corentin Labbe
    Signed-off-by: Herbert Xu

    Corentin Labbe
     

21 Dec, 2018

1 commit

  • The Kconfig lexer supports special characters such as '.' and '/' in
    the parameter context. In my understanding, the reason is just to
    support bare file paths in the source statement.

    I do not see a good reason to complicate Kconfig for the room of
    ambiguity.

    The majority of code already surrounds file paths with double quotes,
    and it makes sense since file paths are constant string literals.

    Make it treewide consistent now.

    Signed-off-by: Masahiro Yamada
    Acked-by: Wolfram Sang
    Acked-by: Geert Uytterhoeven
    Acked-by: Ingo Molnar

    Masahiro Yamada
     

13 Dec, 2018

11 commits

  • crypto_alg_mod_lookup() takes a reference to the hash algorithm but
    crypto_init_shash_spawn() doesn't take ownership of it, hence the
    reference needs to be dropped in adiantum_create().

    Fixes: 059c2a4d8e16 ("crypto: adiantum - add Adiantum support")
    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     
  • CRYPTO_MSG_GETALG in NLM_F_DUMP mode sometimes doesn't return all
    registered crypto algorithms, because it doesn't support incremental
    dumps. crypto_dump_report() only permits itself to be called once, yet
    the netlink subsystem allocates at most ~64 KiB for the skb being dumped
    to. Thus only the first recvmsg() returns data, and it may only include
    a subset of the crypto algorithms even if the user buffer passed to
    recvmsg() is large enough to hold all of them.

    Fix this by using one of the arguments in the netlink_callback structure
    to keep track of the current position in the algorithm list. Then
    userspace can do multiple recvmsg() on the socket after sending the dump
    request. This is the way netlink dumps work elsewhere in the kernel;
    it's unclear why this was different (probably just an oversight).

    Also fix an integer overflow when calculating the dump buffer size hint.

    Fixes: a38f7907b926 ("crypto: Add userspace configuration API")
    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     
  • The 2018-11-28 revision of the Adiantum paper has revised some notation:

    - 'M' was replaced with 'L' (meaning "Left", for the left-hand part of
    the message) in the definition of Adiantum hashing, to avoid confusion
    with the full message
    - ε-almost-∆-universal is now abbreviated as ε-∆U instead of εA∆U
    - "block" is now used only to mean block cipher and Poly1305 blocks

    Also, Adiantum hashing was moved from the appendix to the main paper.

    To avoid confusion, update relevant comments in the code to match.

    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     
  • The kernel's ChaCha20 uses the RFC7539 convention of the nonce being 12
    bytes rather than 8, so actually I only appended 12 random bytes (not
    16) to its test vectors to form 24-byte nonces for the XChaCha20 test
    vectors. The other 4 bytes were just from zero-padding the stream
    position to 8 bytes. Fix the comments above the test vectors.

    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     
  • There is a draft specification for XChaCha20 being worked on. Add the
    XChaCha20 test vector from the appendix so that we can be extra sure the
    kernel's implementation is compatible.

    I also recomputed the ciphertext with XChaCha12 and added it there too,
    to keep the tests for XChaCha20 and XChaCha12 in sync.

    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     
  • Now that the x86_64 SIMD implementations of ChaCha20 and XChaCha20 have
    been refactored to support varying the number of rounds, add support for
    XChaCha12. This is identical to XChaCha20 except for the number of
    rounds, which is 12 instead of 20. This can be used by Adiantum.

    Reviewed-by: Martin Willi
    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     
  • Add an XChaCha20 implementation that is hooked up to the x86_64 SIMD
    implementations of ChaCha20. This can be used by Adiantum.

    An SSSE3 implementation of single-block HChaCha20 is also added so that
    XChaCha20 can use it rather than the generic implementation. This
    required refactoring the ChaCha permutation into its own function.

    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     
  • Add a 64-bit AVX2 implementation of NHPoly1305, an ε-almost-∆-universal
    hash function used in the Adiantum encryption mode. For now, only the
    NH portion is actually AVX2-accelerated; the Poly1305 part is less
    performance-critical so is just implemented in C.

    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     
  • Add a 64-bit SSE2 implementation of NHPoly1305, an ε-almost-∆-universal
    hash function used in the Adiantum encryption mode. For now, only the
    NH portion is actually SSE2-accelerated; the Poly1305 part is less
    performance-critical so is just implemented in C.

    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     
  • If the stream cipher implementation is asynchronous, then the Adiantum
    instance must be flagged as asynchronous as well. Otherwise someone
    asking for a synchronous algorithm can get an asynchronous algorithm.

    There are no asynchronous xchacha12 or xchacha20 implementations yet
    which makes this largely a theoretical issue, but it should be fixed.

    Fixes: 059c2a4d8e16 ("crypto: adiantum - add Adiantum support")
    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     
  • In order to have better coverage of algorithms operating on block
    sizes that are in the ballpark of a VPN packet, add 1472 to the
    block_sizes array.

    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Ard Biesheuvel
     

07 Dec, 2018

12 commits


04 Dec, 2018

1 commit

  • …k/linux-rcu into core/rcu

    Pull RCU changes from Paul E. McKenney:

    - Convert RCU's BUG_ON() and similar calls to WARN_ON() and similar.

    - Replace calls of RCU-bh and RCU-sched update-side functions
    to their vanilla RCU counterparts. This series is a step
    towards complete removal of the RCU-bh and RCU-sched update-side
    functions.

    ( Note that some of these conversions are going upstream via their
    respective maintainers. )

    - Documentation updates, including a number of flavor-consolidation
    updates from Joel Fernandes.

    - Miscellaneous fixes.

    - Automate generation of the initrd filesystem used for
    rcutorture testing.

    - Convert spin_is_locked() assertions to instead use lockdep.

    ( Note that some of these conversions are going upstream via their
    respective maintainers. )

    - SRCU updates, especially including a fix from Dennis Krein
    for a bag-on-head-class bug.

    - RCU torture-test updates.

    Signed-off-by: Ingo Molnar <mingo@kernel.org>

    Ingo Molnar
     

29 Nov, 2018

1 commit

  • In multiple functions, the algorithm fields are read after its reference
    is dropped through crypto_mod_put. In this case, the algorithm memory
    may be freed, resulting in use-after-free bugs. This patch delays the
    put operation until the algorithm is never used.

    Fixes: 79c65d179a40 ("crypto: cbc - Convert to skcipher")
    Fixes: a7d85e06ed80 ("crypto: cfb - add support for Cipher FeedBack mode")
    Fixes: 043a44001b9e ("crypto: pcbc - Convert to skcipher")
    Cc:
    Signed-off-by: Pan Bian
    Signed-off-by: Herbert Xu

    Pan Bian
     

28 Nov, 2018

1 commit


20 Nov, 2018

6 commits

  • Add support for the Adiantum encryption mode. Adiantum was designed by
    Paul Crowley and is specified by our paper:

    Adiantum: length-preserving encryption for entry-level processors
    (https://eprint.iacr.org/2018/720.pdf)

    See our paper for full details; this patch only provides an overview.

    Adiantum is a tweakable, length-preserving encryption mode designed for
    fast and secure disk encryption, especially on CPUs without dedicated
    crypto instructions. Adiantum encrypts each sector using the XChaCha12
    stream cipher, two passes of an ε-almost-∆-universal (εA∆U) hash
    function, and an invocation of the AES-256 block cipher on a single
    16-byte block. On CPUs without AES instructions, Adiantum is much
    faster than AES-XTS; for example, on ARM Cortex-A7, on 4096-byte sectors
    Adiantum encryption is about 4 times faster than AES-256-XTS encryption,
    and decryption about 5 times faster.

    Adiantum is a specialization of the more general HBSH construction. Our
    earlier proposal, HPolyC, was also a HBSH specialization, but it used a
    different εA∆U hash function, one based on Poly1305 only. Adiantum's
    εA∆U hash function, which is based primarily on the "NH" hash function
    like that used in UMAC (RFC4418), is about twice as fast as HPolyC's;
    consequently, Adiantum is about 20% faster than HPolyC.

    This speed comes with no loss of security: Adiantum is provably just as
    secure as HPolyC, in fact slightly *more* secure. Like HPolyC,
    Adiantum's security is reducible to that of XChaCha12 and AES-256,
    subject to a security bound. XChaCha12 itself has a security reduction
    to ChaCha12. Therefore, one need not "trust" Adiantum; one need only
    trust ChaCha12 and AES-256. Note that the εA∆U hash function is only
    used for its proven combinatorical properties so cannot be "broken".

    Adiantum is also a true wide-block encryption mode, so flipping any
    plaintext bit in the sector scrambles the entire ciphertext, and vice
    versa. No other such mode is available in the kernel currently; doing
    the same with XTS scrambles only 16 bytes. Adiantum also supports
    arbitrary-length tweaks and naturally supports any length input >= 16
    bytes without needing "ciphertext stealing".

    For the stream cipher, Adiantum uses XChaCha12 rather than XChaCha20 in
    order to make encryption feasible on the widest range of devices.
    Although the 20-round variant is quite popular, the best known attacks
    on ChaCha are on only 7 rounds, so ChaCha12 still has a substantial
    security margin; in fact, larger than AES-256's. 12-round Salsa20 is
    also the eSTREAM recommendation. For the block cipher, Adiantum uses
    AES-256, despite it having a lower security margin than XChaCha12 and
    needing table lookups, due to AES's extensive adoption and analysis
    making it the obvious first choice. Nevertheless, for flexibility this
    patch also permits the "adiantum" template to be instantiated with
    XChaCha20 and/or with an alternate block cipher.

    We need Adiantum support in the kernel for use in dm-crypt and fscrypt,
    where currently the only other suitable options are block cipher modes
    such as AES-XTS. A big problem with this is that many low-end mobile
    devices (e.g. Android Go phones sold primarily in developing countries,
    as well as some smartwatches) still have CPUs that lack AES
    instructions, e.g. ARM Cortex-A7. Sadly, AES-XTS encryption is much too
    slow to be viable on these devices. We did find that some "lightweight"
    block ciphers are fast enough, but these suffer from problems such as
    not having much cryptanalysis or being too controversial.

    The ChaCha stream cipher has excellent performance but is insecure to
    use directly for disk encryption, since each sector's IV is reused each
    time it is overwritten. Even restricting the threat model to offline
    attacks only isn't enough, since modern flash storage devices don't
    guarantee that "overwrites" are really overwrites, due to wear-leveling.
    Adiantum avoids this problem by constructing a
    "tweakable super-pseudorandom permutation"; this is the strongest
    possible security model for length-preserving encryption.

    Of course, storing random nonces along with the ciphertext would be the
    ideal solution. But doing that with existing hardware and filesystems
    runs into major practical problems; in most cases it would require data
    journaling (like dm-integrity) which severely degrades performance.
    Thus, for now length-preserving encryption is still needed.

    Signed-off-by: Eric Biggers
    Reviewed-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Eric Biggers
     
  • Add a generic implementation of NHPoly1305, an ε-almost-∆-universal hash
    function used in the Adiantum encryption mode.

    CONFIG_NHPOLY1305 is not selectable by itself since there won't be any
    real reason to enable it without also enabling Adiantum support.

    Signed-off-by: Eric Biggers
    Acked-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Eric Biggers
     
  • Expose a low-level Poly1305 API which implements the
    ε-almost-∆-universal (εA∆U) hash function underlying the Poly1305 MAC
    and supports block-aligned inputs only.

    This is needed for Adiantum hashing, which builds an εA∆U hash function
    from NH and a polynomial evaluation in GF(2^{130}-5); this polynomial
    evaluation is identical to the one the Poly1305 MAC does. However, the
    crypto_shash Poly1305 API isn't very appropriate for this because its
    calling convention assumes it is used as a MAC, with a 32-byte "one-time
    key" provided for every digest.

    But by design, in Adiantum hashing the performance of the polynomial
    evaluation isn't nearly as critical as NH. So it suffices to just have
    some C helper functions. Thus, this patch adds such functions.

    Acked-by: Martin Willi
    Signed-off-by: Eric Biggers
    Acked-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Eric Biggers
     
  • In preparation for exposing a low-level Poly1305 API which implements
    the ε-almost-∆-universal (εA∆U) hash function underlying the Poly1305
    MAC and supports block-aligned inputs only, create structures
    poly1305_key and poly1305_state which hold the limbs of the Poly1305
    "r" key and accumulator, respectively.

    These structures could actually have the same type (e.g. poly1305_val),
    but different types are preferable, to prevent misuse.

    Acked-by: Martin Willi
    Signed-off-by: Eric Biggers
    Acked-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Eric Biggers
     
  • Now that the generic implementation of ChaCha20 has been refactored to
    allow varying the number of rounds, add support for XChaCha12, which is
    the XSalsa construction applied to ChaCha12. ChaCha12 is one of the
    three ciphers specified by the original ChaCha paper
    (https://cr.yp.to/chacha/chacha-20080128.pdf: "ChaCha, a variant of
    Salsa20"), alongside ChaCha8 and ChaCha20. ChaCha12 is faster than
    ChaCha20 but has a lower, but still large, security margin.

    We need XChaCha12 support so that it can be used in the Adiantum
    encryption mode, which enables disk/file encryption on low-end mobile
    devices where AES-XTS is too slow as the CPUs lack AES instructions.

    We'd prefer XChaCha20 (the more popular variant), but it's too slow on
    some of our target devices, so at least in some cases we do need the
    XChaCha12-based version. In more detail, the problem is that Adiantum
    is still much slower than we're happy with, and encryption still has a
    quite noticeable effect on the feel of low-end devices. Users and
    vendors push back hard against encryption that degrades the user
    experience, which always risks encryption being disabled entirely. So
    we need to choose the fastest option that gives us a solid margin of
    security, and here that's XChaCha12. The best known attack on ChaCha
    breaks only 7 rounds and has 2^235 time complexity, so ChaCha12's
    security margin is still better than AES-256's. Much has been learned
    about cryptanalysis of ARX ciphers since Salsa20 was originally designed
    in 2005, and it now seems we can be comfortable with a smaller number of
    rounds. The eSTREAM project also suggests the 12-round version of
    Salsa20 as providing the best balance among the different variants:
    combining very good performance with a "comfortable margin of security".

    Note that it would be trivial to add vanilla ChaCha12 in addition to
    XChaCha12. However, it's unneeded for now and therefore is omitted.

    As discussed in the patch that introduced XChaCha20 support, I
    considered splitting the code into separate chacha-common, chacha20,
    xchacha20, and xchacha12 modules, so that these algorithms could be
    enabled/disabled independently. However, since nearly all the code is
    shared anyway, I ultimately decided there would have been little benefit
    to the added complexity.

    Reviewed-by: Ard Biesheuvel
    Acked-by: Martin Willi
    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     
  • In preparation for adding XChaCha12 support, rename/refactor
    chacha20-generic to support different numbers of rounds. The
    justification for needing XChaCha12 support is explained in more detail
    in the patch "crypto: chacha - add XChaCha12 support".

    The only difference between ChaCha{8,12,20} are the number of rounds
    itself; all other parts of the algorithm are the same. Therefore,
    remove the "20" from all definitions, structures, functions, files, etc.
    that will be shared by all ChaCha versions.

    Also make ->setkey() store the round count in the chacha_ctx (previously
    chacha20_ctx). The generic code then passes the round count through to
    chacha_block(). There will be a ->setkey() function for each explicitly
    allowed round count; the encrypt/decrypt functions will be the same. I
    decided not to do it the opposite way (same ->setkey() function for all
    round counts, with different encrypt/decrypt functions) because that
    would have required more boilerplate code in architecture-specific
    implementations of ChaCha and XChaCha.

    Reviewed-by: Ard Biesheuvel
    Acked-by: Martin Willi
    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers