# Tag Info

14

The library uses XChaCha20Poly1305 and that requires a nonce of 192-bit (24-byte). It is an extension of ChaCha20Poly1305 to increase the nonce size, ChaCha20 had 96-bit nonces. There is no standard for it, only a draft in ietf.org The nonce is an acronym for 'number used once'. The crucial point is that one must never use the (Key, nonce) pair again. We ...

10

There's simply no way to know. I find it very unlikely that AES will be vulnerable to a ciphertext-only attack in the next 20 years (remember, it has been around for over 20 years already and attacks haven't gotten very far). There's no reason to believe the same won't be true for ChaCha20. If you use a good cipher with 256-bit keys (to avoid potential ...

9

idle speculation, my personal favourite! i always thought it was after the dance... Salsa dance - see the video (Video demonstrating salsa dancing fundamentals) and jump to ~1min05sec in, the section titled: "side-side-quarter-turns", if you'd prefer to remain seated... and from (https://en.wikipedia.org/wiki/Salsa20), The Salsa quarter-round function. ...

7

When I was writing a paper for a cryptosystem which uses salsa20 as a CSPRNG I read some papers related to it, starting from those published by the designer of Salsa20 (2005) and Chacha20 (2008), Daniel J. Bernstein. I have to tell you I didn't ask this interesting question before. Because of you I revisited my citations and I realised Daniel didn't explain ...

5

The RFC 7539 describe your needs. The uniqueness: The most important security consideration in implementing this document is the uniqueness of the nonce used in ChaCha20. Counters and LFSRs are both acceptable ways of generating unique nonces, as is encrypting a counter using a 64-bit cipher such as DES. Note that it is not acceptable to use a truncation ...

4

Yes, it can be implemented as an AEAD cipher, although the common definition uses ChaCha20 instead. ChaCha is a cipher with slightly better diffusion and better performance characteristics; both ciphers are by Daniel Bernstein. If you want to use Salsa instead, then just replace ChaCha20 with Salsa20 - but I would rather not do that. ChaCha20 / Poly1305 is ...

4

You shouldn't encrypt large files as if they were just one message; you should split them up into small chunks and encrypt each chunk separately with an AEAD, using some construction that: Protects against modification, reordering, insertion and deletion of chunks; Protects against truncation of the file; Rotates keys once too much data has been processed ...

3

Specifically, is it safe to re-use the same nonce for decryption an indefinite amount of times, if you only use it once for encryption? Indeed, all good security definitions (under which ciphers are proven secure) will place no restrictions on the input of the decryption algorithm. The intution behind this is that the the input to the encryption algorithm ...

3

You should generate a random* nonce and store it alongside the ciphertext, e.g. prepended to it. Both ChaCha20 and Poly1305 require a unique nonce to be used for each encryption, otherwise they will not be secure. However, the nonce does not need to be kept secret, so you can just include it with the ciphertext. *) Technically, the nonce for ChaCha20–...

3

If the ciphertext is the same size as the plaintext, then yes with 100% probability. There are only finitely many values the ciphertext can take. So repeatedly encrypting the ciphertext, means that a value must repeat eventually. If this cycle doesn't include the original message, then there is some ciphertext that has an ambiguous decryption (because two ...

3

No it doesn't matter, as you won't be switching the nonce on a per message basis, just outputting a stream of random data. However, remember, your key will only produce an output stream valid until the internal counter overflows. Consider XChaCha20. IETF ChaCha20 uses a 96-bit nonce and 32-bit counter, XChaCha20 uses a 192-bit nonce and 64-bit counter. The ...

2

ChaCha20 is a stream cipher, therefore, knowledge can be used. Let see what one can do. When it comes to key rotation, you'll need to store those encrypted values twice, for a short period of time (under the old and new keys). This means that the attacker has a chance to see these $C_1 = P\oplus K_1$ and $C_2 = P\oplus K_2$. X-oring these two ciphertexts;...

2

Is it secure to use the same shared symmetric key, used for encryption with the arbitrary generation of a new nonce per message, for unlinkable contact signaling? Yes, as long as adversaries do not manage to get hold on the key. That condition implies None of the multiple holders of the key in the proposed system are adversaries. Each is competent at ...

2

The fact that few bits change at the input of ChaCha's "core" function does not compromise the security of the ChaCha20 stream cipher. The design principle of the stream ciphers Salsa and Chacha is to use a "core" function $C:\,\{0,1\}^{512}\to\{0,1\}^{512}$ over the set of 512-bit bitstring (equivalently the set fo 16 words each 32-bit). Among the 512 ...

2

This answer has 2 parts, the 1st on "quantifying" the security of unbroken ciphers, the 2nd on the choice of ciphers for different usage scenarios. If (on a scale of 1 to 10) AES is 5 and Serpent is 10, what would ChaCha be? First, you have to quantify their security in order for the scores to be meaningful. The quantification must have a basis, ...

1

Because all requests are encrypted with the session key, can that act as a form of proof that the client is the real owner of the session ID? e.g. If the session ID somehow is stolen, it can still not be used to communicate to the backend as you still would need to have ownership over the shared secret. That depends. I don't see any explicit check for this ...

1

Since you have ChaCha20 as the cipher, it shouldn't occupy too much resource to add a BLAKE2 hash function next to it. The BLAKE2 hash function comes in 2 variants: BLAKE2b, and BLAKE2s. ChaCha20 uses 32-bit words, which is more compatible with BLAKE2s. The only major difference between the hash and the cipher are the shift/rotate amounts, and the HAIFA hash ...

1

First the XChaCha20-Poly1305 basics Why one may need XChaCha20 ChaCha20 is 20 round from the ChaCha family. The Bernstein version of ChaChax has a 64-bit nonce and 64 bit counter. Bernstein argued that this should be enough in the XSalsa paper There is a standard argument that a 64-bit nonce is long enough. Nonce security does not mean unpredictability; it ...

1

My question is that Poly1305 provide authentication and Salsa20 provides encryption, a combination of both can be considered AEAD or not? There are many ways you could combine both, some are AEADs and some are not. For example: RFC 8439 ("ChaCha20 and Poly1305 for IETF Protocols") specifies a combination of ChaCha20 and Poly1305 that is an AEAD. You ...

1

Actually, by your own criterion, the same nonce is routinely used much more than twice, because each call to the ChaCha20 core function reuses the same key and nonce, except with a different counter value. Here's the problem that's tripping you up: the prohibition on using the same key/nonce pair to encrypt more than one message applies to the construction'...

1

Of course, it's used as an AEAD ! AEAD stands for Authenticated Encryption with Associated Data It gives confidentiality as well as authenticity to your encryption, which simply means that the data is encrypted and that no one can alter any bit of your data. The alteration if done will be detected during verification. ChaCha, Salsa, including their ...

1

JP Aumasson has created the Blabla generator, based on BLAKE2b (64-bit), which is very similar to Chacha/Salsa. In my tests, it does not seem vastly faster than concatenating two consecutive outputs of Chacha. https://github.com/veorq/blabla/blob/master/BlaBla.swift

1

Not sure if my speed test could help to get an idea on this topic. ChaCha20-IETF-Poly1305 is actually now 10% slower than AES-256-GCM on my mobile TLS speed test in 2020, even since 2019. AES-256-GCM was much slower back in 2015, but I had lower-end CPU back then. I can not run SSH on mobile as it isn't rooted, but on the desktop I can't find the differences....

Only top voted, non community-wiki answers of a minimum length are eligible