Search Results

As long as the AES mode uses an IV and the IV is different for each message, there will be no patterns in the ciphertext. However, there may be other attacks. … Either AES in GCM mode or AES CTR + HMAC would work, for example. That will also prevent changes to messages, which may currently allow an attacker to change the device status in a message. …

That means "88 characters" could be one IV + three blocks of AES output (512 bits in base 64 = 85.33 + 2.67 padding). …

Since there are only $16^6 \approx 16.8$ million keys, you can try them all and decrypt the message with each. In general you would have to know something about the plaintext to identify which of thos …

Additionally, use authenticated encryption (e.g. either AES GCM or AES CTR + HMAC). …

Like said in the comments, a 256-bit message is two blocks of AES, no matter the keysize. … The main issue with ECB mode (i.e. using AES directly on 128-bit blocks) is that you leak whether two blocks are equal. …

If we take some randomly generated key of AES-128 and we change any random 1 byte of that 16 byte key, will this make huge difference in the AES cipher text generated over same input string? … However, that's not a very realistic attack in practice, and anyway AFAIK they only exist on AES-192 and AES-256, not (the full 10 rounds of) AES-128. …

The probability that $E_{k_1}(p) = k_1$ is $2^{-128}$ for a given $p$, but must be true for some $p$ with every AES-128 key $k_1$. …

If $f_k$ is AES the block cipher, then there are $2^{128}$ possible output values for a given plaintext and $2^{|k|}$ possible AES keys, where $|k|$ is either 128, 192 or 256, depending on which AES key … With AES-192 and AES-256 there are always some colliding keys for every plaintext. You expect every key to have (many) other keys that produce the same ciphertext. …

. $2^{39}$ bits with AES. The 256 bits that are subtracted are due to authentication. So you can encrypt multiple maximum-length messages securely. …

A slight correction about terminology: The key is constant when you use CTR. The IV/counter affect the cipher input and so the keystream varies. The reason this can be decrypted is that the decryp …

Salt and IV do not need to be secret, but should be unique. If I understand correctly, the Rfc2898DeriveBytes class generates a random salt? In that case you are fine. 64 bytes is (more than) enough …

If an attacker had tampered with the nonce $n$, AES CTR would happily decrypt your message but give you random data. …

If the protocol doesn't provide authentication, an attacker can probably mount replay attacks or make deterministic changes to messages. If the nonces in different blocks are not compared in any way, …

There are two possibilities here: AES is secure, in which case no one can open your encryption without knowing your keys, regardless of whether you layer anything else on top of AES. … Perhaps Twofish or Serpent (both AES runners up), or Rabbit or Salsa20 (eSTREAM winners). …

Yes, it's secure. It is somewhat overkill, however, since you could stop replay attacks by using either: a persistent counter as IV, or a random nonce, and including a timestamp in the message. T …