# Tag Info

0

The two plaintexts are almost certainly identical. At the very least, any difference between them must be representable in 32 bytes, since that's as much information as the XOR of the encrypted files contains. Assuming that the plaintexts are indeed identical, we can also see that changing the encryption key has a very simple and predictable effect on the ...

3

For simple XOR-based encryption algorithms such as OTP, the key size must be the same as the message size. If you choose a smaller key and try to divide the message into chunks, you would not have a perfectly secure scheme anymore. Now, since you tagged java, I'm assuming that this increase in time for smaller key sizes is due to the code trying to divide ...

6

Some brief thoughts: Shared secret Generation: $$s=E_a(B)=E_b(A)$$ The shared secret is generated by encrypting the other users public key with your private key. This is effectively an ECDH step, which is very reasonable, and one of the key aims of C25519$^{[1]}$. Key Generation: $$s_0=\mathrm{SHA256}(s); s_i=\mathrm{SHA256}(s_{i-1})$$ First, using the ...

1

For CBC mode, the IV must be Never used twice with the same key Unpredictable So, in your example (filename$\oplus$key), if you ever encrypt two files that have the same filename with the same key, you will violate #1. Now, you may be tempted to say "but I always generate a new key for every file that I encrypt, so that example doesn't apply". Fine, ...

Top 50 recent answers are included