Tag Info

New answers tagged

1

AES transformation can be viewed as a sequence of invertible transformations each processing only a small part of the state. All these transformations would be even, and so is the entire AES for any key (see also this question).


0

In the decrypting steps use AES_encrypt itself instead of AES_decrypt, AES decrypt is never needed. Remember while encrypting, AES_encrypt is only used as a Pseudo Random Function, we don't really need AES_decrypt method even in decrypting phase. This might seem little confusing at first but not needed. Please check the proof given for this answer


0

I understand your question to be related with stream encoding by XORing a source using the bytes emitted from two by XORed PRNG. (By the way, you don't need to combine them before XOR the source - the result remains the same, if you XOR the source by bytes from both PRNGs in the same sequence.) I guess, you want to be able to decipher the result back to the ...


0

You are attempting to perform a distinguishing attack. Since neither cipher has a known attack of this sort, I suggest you find an unbiased coin and flip it.


1

When you are e.g. sending TLS encrypted data over a SSH tunnel, there are two things in particular that should be noted: The TLS handshake will only commence, once the SSH connection has been established. The bulk encryption keys of TLS will be completely independent of the SSH encryption keys. Since the handshakes and keys are completely independent, ...


1

Any good software should use PBKDF (a password based key derivation function) that uses a random salt. This salt is stored with the ciphertext and should be different for each ciphertext. As long as this is the case they key will be different for each ciphertext. The best way an attacker can then attack your ciphertext (when stored on disk) is to iterate ...


0

It really depends on you block cipher mode of operation and likeliness between your files. With any proper implementation, it should really not, but since you don't really give any details about your encryption scheme, it's hard to tell. (side-note: how do you derive the key from the password?)


1

It's a hardware implementation of something that typically needs to be written in software. Imagine if nobody had hardware multiplication circuits and everybody had to write software implementations of multiplication. Then a new processor came out that had a dedicated circuit to perform multiplication. Obviously a circuit for multiplying numbers would be ...


4

AES-NI is just a fast way for the processor to execute the calculations of AES. Normally the computer has to calculate every single step of the AES key schedule and the rounds as a single instruction: Substitute it with the S-boxes, shift the rows, mix the columns, XOR the round key. This is called a software implementation. Every instruction has to be done ...


1

If you start with a random key and zero counter, there's 128 bits of entropy in the system state. If you start with a random key and random counter value, there's 256 bits of entropy. Whether that matters depends on what you are using the PRNG output for. If you are using the output for anything where 256 bits of entropy would be an asset – say random ...


1

When using counter mode you can start at any value, it doesn't matter. The only important thing is that you never use the same counter value twice for the lifetime of the key. So, as long as your key is actually random and, as you say, you don't use it for more than 1 MB of data, then your generator should be fine.


1

There's no particular computation you have to do. Since all other tables could be computed just by rotations of Te0 what you need is just to perform rotations, xors and table lookups. Here's what usually done when you have only Te0. You read the state column-wise, keeping in one 32 bit variable/register the value of one column. (As convention hereafter, ...


0

Currently you seem to be using a Password Based KDF (PBKDF); you are using PBKDF2, as defined in Rfc2898. You don't need to do this as randomly generated data is already fine for creating an AES key. So - as you don't need a PBKDF - you don't actually need a salt. If you need more keys or key data then what is actually required is a Key Based KDF (KBKDF), ...


4

Like the other answers say, it does not always have to be the case. One other case where it is often not stored is when you have a single use key, for example as part of some hybrid encryption scheme. Then there is no need to use a nonce at all and it is usually taken to have zero value.


5

If you want strict indistinguishability, then yes, you need to store the IV (initial counter) somewhere. However, there are some relaxed modes that are used in practice for things like disk encryption, where it is often very useful to decrypt things "in the middle" like you say. For instance, XEX uses a counter which is derived from the sector and offset ...


7

I would like to ask if that is true for every AES CTR mode implementation?, Doesn't have to be. You can store the nonce anywhere. You could even send it to the recipient via a different channel (e.g., email the ciphertext and use SMS to transmit the nonce). Storing it at the beginning has its advantages. For example, if streaming the data, you can ...


1

As you can make up from this encryption scheme, I'm using the encrypt-then-authenticate approach to enforce ciphertext integrity. In step 2 of the decryption process I perform this authentication step. If the calculated HMAC turns out to be equal to the HMAC in the file, does this mean, apart from the implied ciphertext integrity, that the supplied ...


2

CCM (Counter with CBC-MAC) Message authentication (via CBC-MAC) is done on the plaintext not the ciphertext. (This is generally not a desireable feature.) On the encrypt operation, the encryption and MAC could happen in parallel, but generally do not (typically because there is just one AES engine in a chip, just one AES thread at a time, etc.). Similar ...


3

I am little curious about how do we calculate hardness proof of any cryptography algorithm? This is typically done by assuming some problem is hard (e.g., solving discrete log). Then proving that if someone can break the cryptography algorithm (e.g., diffie-hellman) that they can also break the hard problem. Once this relationship is established, we ...



Top 50 recent answers are included