Giter Club home page Giter Club logo

libsodium-xchacha20-siv's Introduction

XChaCha20-SIV

Deterministic/nonce-reuse resistant authenticated encryption scheme using XChaCha20, implemented on libsodium.

XChaCha20-Poly1305 XChaCha20-SIV
Key size 256 bits 256 bits (before expansion)
Authentication tag 128 bits 256 bits
Nonce 192 bits, mandatory Optional
Nonce reuse Can leak plaintext Only leaks message duplication
Speed Fast Slightly slower

Usage

int crypto_aead_det_xchacha20_encrypt_detached(
    unsigned char *c,
    unsigned char mac[crypto_aead_det_xchacha20_ABYTES],
    const unsigned char *m, size_t mlen,
    const unsigned char *ad, size_t adlen,
    const unsigned char *nonce,
    const unsigned char k[crypto_aead_det_xchacha20_KEYBYTES]);

Encrypt a message m of length mlen bytes using a key k, an optional nonce nonce (which can left to NULL), optionally authenticating additional data ad (if not NULL) of length adlen bytes in addition to the message itself. The IV acting as a MAC is stored into mac.

int crypto_aead_det_xchacha20_decrypt_detached(
    unsigned char *m,
    const unsigned char *c, size_t clen,
    const unsigned char mac[crypto_aead_det_xchacha20_ABYTES],
    const unsigned char *ad, size_t adlen,
    const unsigned char *nonce,
    const unsigned char k[crypto_aead_det_xchacha20_KEYBYTES]);

Decrypt a ciphertext c or length clen bytes using a key k, an optional nonce nonce (which can be left to NULL), optionally verifying additional data ad (if not NULL) of length adlen bytes in addition to the message itself, using the MAC mac.

The function returns -1 if the authentication tag didn't verify, and 0 on success, storing the decrypted message into m.

int crypto_aead_det_xchacha20_encrypt(unsigned char *c,
                                      const unsigned char *m, size_t mlen,
                                      const unsigned char *ad, size_t adlen,
                                      const unsigned char *nonce,
                                      const unsigned char  k[crypto_aead_det_xchacha20_KEYBYTES]);

Similar to encrypt_detached, but the ciphertext and MAC are concatenated.

c must be mlen + crypto_aead_det_xchacha20_ABYTES long.

int crypto_aead_det_xchacha20_decrypt(unsigned char *m,
                                      const unsigned char *c, size_t clen,
                                      const unsigned char *ad, size_t adlen,
                                      const unsigned char *nonce,
                                      const unsigned char k[crypto_aead_det_xchacha20_KEYBYTES]);

Similar to decrypt_detached, with the ciphertext and the MAC having been concatenated.

void crypto_aead_det_xchacha20_keygen(unsigned char k[crypto_aead_det_xchacha20_KEYBYTES]);

Create a 256-bit secret key.

libsodium-xchacha20-siv's People

Contributors

jedisct1 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

libsodium-xchacha20-siv's Issues

Document where the design for `s2v` comes from

Looking at the implementation of s2v it resembles the S2V construct from RFC 5297.

The only difference I see, besides the choice of hash function and sizes, is that if the message is less than the MAC size, you apply an extra d[mlen] ^= 0x80;.

Am I correct?

[question] An alternate simpler `s2v` that just uses `libsodium` primitives

(This is not a bug, but an implementation decision question. I would have posted this into the GitHub discussions, but that was not enabled at the moment for this repository.)


Looking at the implementation crypto_aead_det_xchacha20_encrypt_detached (and counterpart) they are quite straight-forward to implement, with the exception of the s2v function that generates the actual nonce for XChaCha20.

Please view this in the context of someone that just has access to the standard libsodium (or equivalent) library, and would like to implement something similar based on SIVs. Therefore implementing s2v, especially correctly, is far from the reach of most developers, myself included.

Thus, my question is: couldn't one implement s2v by just leveraging the crypto_generichash_* family of functions?


For example, copy-pasting from RFC 5297 the basic design of that S2V (which I'm assuming, as per #1, was the inspiration for the current s2v in this repository) is:

                  +----+       +----+       +------+      +----+
                  | S1 |       | S2 | . . . | Sn-1 |      | Sn |
                  +----+       +----+       +------+      +----+
     <zero>   K     |            |             |             |
       |      |     |            |             |             V
       V      |     V            V             V    /----> xorend
   +-----+    |  +-----+      +-----+       +-----+ |        |
   | AES-|<----->| AES-|  K-->| AES-|  K--->| AES-| |        |
   | CMAC|       | CMAC|      | CMAC|       | CMAC| |        |
   +-----+       +-----+      +-----+       +-----+ |        V
       |           |             |             |    |     +-----+
       |           |             |             |    | K-->| AES-|
       |           |             |             |    |     | CMAC|
       |           |             |             |    |     +-----+
       \-> dbl -> xor -> dbl -> xor -> dbl -> xor---/        |
                                                             V
                                                           +---+
                                                           | V |
                                                           +---+

(Here, the RFC S2V accepts zero or more additional data, and the plain text is fed into the last Sn.)

Couldn't one replace this schema with the following simpler alternative:

  • let Hn be the hash (using crypto_generichash) each of the Sn parts using the same key K; (these values could be then cached in case one of the Sn's are somewhat constant, as the RFC suggests;)
  • let V (i.e. the MAC/nonce) be the hash (again using crypto_generichash) with key K of the concatenation of the previous Hn hashes;

Alternatively, if one doesn't care about caching partial hashes, wouldn't the hash of a canonical representation of the sequence Sn be enough? (i.e. hash sizeof(S1) || S1 || sizeof(S2) || S2 || ...)

My assumption is that the current construction of S2V from the RFC uses the "doubling and xor" method because it is far more efficient than just feeding everything back into another AES-CMAC (or the Blake family in our case). Or is there another property that I'm missing?


I've tried reading (truthfully more skimming through) the original Deterministic Authenticated-Encryption: A Provable-Security Treatment of the Key-Wrap Problem paper that introduced SIVs, which in section 5, "Enriching a PRF to take Vectors of Strings as Input: The S2V Construction", does seem to hint exactly to what I've asserted above; quoting the paper:

At first glance it might seem like there’d be little to say about sPRF-to-vPRF conversion: there’s an obvious approach for solving the problem, and it’s obviously correct.

Namely, encode any vector of strings X = (X1, . . . , Xm ) into a single string X and apply the sPRF to that. By encode we mean any reversible, easily-computed map of a vector of strings into a single one, say X1, . . . , Xm = X1 || N1 || · · · || Xm || Nm where Ni = |Xi|64 is the length of Xi encoded into 64 bits.

The problem with making a vPRF in such a way is a diminution of efficiency.

(From there on it's hard for me to follow...)


I am not a cryptographer, I just want to make sense of all these, thus any feedback is welcome.

Thanks!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.