Tag Info

Hot answers tagged

11

Decrypt the ciphertext with every possible key and store the result: $2^{56}$ decryptions. Now encrypt the (known) plaintext of the ciphertext with every possible key: $2^{56}$ encryptions. Now you have to check every entry, which is in both lists and try it with another plaintext-ciphertext pair. If you can successfully decrypt that, you are very likely to ...


5

Here are some hints on how it's done on Mega: The password provided is passed through a KDF to derive a key, that is used to en-/decrypt the master key (later provided by the server through an API call). To bring it down to the crucial bits: The KDF applies $2^{16}$ rounds of AES-128 with it. The details can be found in the function prepare_key() of the ...


3

Simply put: No. First recall that this is a mis-use of the term "One Time Pad" So lets call it a vigenere cipher instead. You can determine this is insecure with a simple algebraic combination: $ \text{attack} = cipher_1 + cipher_2 + cipher_3 + cipher_4 \\ \text{Simplify: } \\ \text{attack} = character_1 + key_1 + IV_1 + character_2 + key_2 + IV_1 + ...


2

Key generation and key scheduling are different things. The key scheduling is part of the cipher, the key generation generally isn't. Symmetric keys should be indistinguishable from random, so often they are the product of a secure random number generator. There are other ways as well, such as derivation from a password using a Password Based Key Derivation ...


1

It seems you want some sort of anonymization, and you already jump to a conclusion with encrypting symbols. Maybe you should step away of that for a moment, and ask yourself what your actual goal is. Encryption is useful, if you want to be able to reverse that process. If you don't hashing is a better choice in general. Your set is small enough that you ...


1

First, you wouldn't call it a one-time-pad any longer if you reused the key. Second the security of the OTP can only be proven if the key is as long as the message. (which wouldn't be the case if you'd reuse a key) Third, OTP usually use XOR operation to combine key and message. If the key is never reused, you're safe, but if an attacker can mount a known ...


1

The keystream is as long as the message, so you don't want to send that to the receiver. The keystream is generated by a much shorter key (e.g., 128-bit private key). That is what the receiver needs in order to decrypt the message. So, how do you get that to the receiver? Well, clearly you can't just send it in the clear or anyone watching the channel would ...


1

Anyone who has the keystream and the ciphertext can trivially calculate the plaintext — it's a xor operation bit by bit. Sending the keystream alongside the ciphertext would completely defeat the purpose of encryption. The principle of stream ciphers is that the sender and the receiver agree on an algorithm, a secret key and some parameters, and both ...



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