I learnt that you could use the key as a AES Key & encrypt the session with AES. Or you could use something like Elgamal encryption.
Elgamal encryption could be used directly with a static private key. The key type would be identical to the one used for (static or ephemeral) Diffie-Hellman. However, it would not be efficient both when it comes to space ...
Yes, and Key-Encryption Keys often are symmetric. When they are, they do not bring the benefits of asymmetric cryptography; in particular, anyone with the KEK and passively eavesdropped ciphertext can decrypt the distributed keys. That does not make use of symmetric KEK pointless:
KEK would typically be distributed, stored and used with more precautions (...
Another option would be to store the nonce is the server side with the encrypted data or in external service. This way you don't need the user to keep it or even to be aware of it and your application should know how to fetch it for decryption when needed.
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–...
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 ...
a one time pad ia very different from other fixed key ciphers.
A one time pad is just a xor(or modular addition) It does not miz anything or extend key and even a tiny bit of key reuse is very problematic.
We have stream ciphers which take a key and produce an infinite stream of pseudo random bits.
Perhaps what you are asking for is for a cipher with ...
There are two main ways to have the same symmetric key on both parties:
key exchange using asymmetric crypto
generate the key from a known secret (eg: a password), such as using a password-based key-derivation function
The former is what you will find in TLS, where public key infrastructure is used to verify the other party's public key.
The latter is used ...
I believe I have settled it, please comment below if I have inaccuracies or am missing something:
We can also represent these as the following: (by applying the appropriate decryptions to either side)
Dk4(Dk5(c)) = Ek3(Ek2(Ek1(m))) _____ OR ______ Dk3(Dk4(Dk5(c)))=Ek2(Ek1(m))
Effective key length: with the mitm attacker, it would ...