Tag Info

Hot answers tagged

6

AES-CTR is a stream cipher, of a particular kind where the keystream is obtained by encryption of a counter. So the question reduces to: what are drawbacks of AES-CTR compared to other stream ciphers? The main ones compared to ChaCha20 are: Without hardware support, AES can fail to cache-timing attacks. Without hardware support, AES is slower. Without ...


4

There are two things here: Encryption uses mode of operation, and not "AES alone". Some of them are randomized by an initialization vector - that means the encryption of the same text under the same algorithm is still randomized and not deterministic. The encryption methods take care of that. You only need the correct key to decrypt. Passwords are not ...


4

First, AES-CTR isn't "similar to a stream cipher." It is a stream cipher. That means the real question is "why do we develop new stream ciphers when AES-CTR provides an acceptable one?" The answer is that newer stream ciphers tend to be superior to AES in some way or another. AES is a secure cipher, but it has some bad properties; for instance, it's hard ...


3

AES is not provably secure, for the simple reason that there is no security proof for it. We suspect that AES is secure in practice, but there is no proof of that.


3

You benchmarked a highly optimized AES implementation against a reference implementation of CLEFIA: * NOTICE * This reference code is written for a clear understanding of the CLEFIA * blockcipher algorithm based on the specification of CLEFIA. * Therefore, this code does not include any optimizations for * high-speed or low-cost implementations or any ...


2

No. First, you've exposed a padding oracle by using unauthenticated AES. Secondly, you've not authenticated the devices: it's easy to mount a man in the middle attack. Thirdly, I don't understand the role of changing parameters all the time in your protocol.


2

It you need a deterministically derived key for AES, the DRBG algorithms of NIST SP 800-90A are suitable, and their output is directly usable as an AES key. An example use case is when computing an AES session key from a longer-term master key, and the nonce corresponding to that session. AES will expand its key (128, 192 or 256-bit) to 128-bit subkeys (one ...


2

I think you meant brute force when you mention, it would take trillions(?) years to break AES. So your "provably secure" category boils downs to brute forcing the algorithm which is not considered "breaking" the algorithm. AES is kind of a successor to DES (at least for an initial understanding) which had been in use for quite a long time and was not broken ...


1

That's because AES is not a password-based encryption algorithm. It's a block cipher. It may seem like a detail, but such details matter. In cryptography, and in security in general, details often matter. AES is a pair of functions, each of which takes a key and a 128-bit message and produces a 128-bit message. The two functions are called encryption and ...


1

I would prefer to use standardized (like FIPS 140-2) secure random generator, since the whole point is to secure the encryption key. Of course, you might want to check this website for reference: http://www.cryptosys.net/rng_algorithms.html


1

Yes this would work as stated by you. Explanation: If you're using a library supporting ECB (which you are actually using in this example) you can input the whole 32 bytes of plaintext and will receive the corresponding 32 bytes of ciphertext. Splitting the operation into two calls doesn't make any difference for libraries as internally they do nothing ...


1

Cipher Feedback mode turns the block cipher (AES) into a self-synchronizing stream cipher which feeds back the full ciphertext block as the next IV. If you encrypt something smaller than a multiple of the block size, it will not use all of the block cipher output to create the ciphertext, just the amount it needs. Therefore there is not a padding ...



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