cesarb
commented
8 years ago I took a quick look at the link you provided, and it seems that a little more is needed. In particular, it uses a 64-bit counter and a 64-bit IV, and seems to have no padding between the AAD and the ciphertext. The AEAD part of this crate currently exploits the fact that, in the RFC 7539 variant, everything is a multiple of the Poly1305 block size.
Due to the potential for misuse, I would prefer to avoid exporting the raw ChaCha20 and Poly1305 primitives. But I believe it does make sense to implement the openssh variant in this crate, as an "openssh" module, with whichever API better fits the use case.
I won't have time to look at it for a while, but in case you want to do the work yourself, you'll just need to add the "with_long_counter" (variation of "with_counter") and "next_with_long_counter" (variation of "next") functions to the ChaCha20 impl, to be able to use a 64-bit counter and a 64-bit IV, and the rest (struct for the K_1 instance, buffering for the stream cipher, key derivation, AEAD encrypt/decrypt) can be done in the "openssh" module. You'll also need to find test vectors somewhere, to validate the implementation.
Currently this crate only exposes the top level aead functions. Unfortunately this is not enough when attempting to use this crate for chacha20-poly1305@openssh.com. In particular, being able to use a raw instance of ChaCha20 (to encrypt packet lengths without authentication), and being able to explicitly set the ChaCha20 block counter used in the aead, is needed. This could either be exposed by making the Chacha20 module public and adding flexiblility to the aead routine, or by providing explicit chacha20-poly1305@openssh.com routines. In the current state, supporting chacha20-poly1305@openssh.com requires either an unnecessary fork of this module or a complete reimplementation, both of which would be a shame.