Tag Info

I'm just curious to know why the 128-bit version become the standard[.] That question is easy to respond. In the section Minimum Acceptability Requirements of Request for Candidate Algorithm Nominations for the AES, it says: The candidate algorithm shall be capable of supporting key-block combinations with sizes of 128-128, 192-128, and 256-128 ...

I can immediately think of four reasons: They're both not using AES256. I see in the Obj-C document a direct statement that they are using AES256 (unless you deliberately change it), I don't see any statement in the Visual Basic document that says what key size they're using (unless that's what they mean by "Block Bits"). Different keys. AES256 takes a ...

Rijndael (the algorithm behind AES) is specified with block sizes and key sizes of 128, 160, 192, 224 and 256, in any combination of block and key size. (Thus, Wikipedia was wrong with the keysize has no theoretical maximum here, though one could invent extensions of the key schedule algorithm which allow longer keys. See below for details. I now fixed this ...

That variation directly implements Rinjdael's ShiftRow as specified (section 4.2.2) in the proposal to NIST, defining Shitftrows for 128, 192 and 256-bit block size (Nb=4, 6 and 8). Loosely speaking, the offsets improve the mixing (diffusion) properties of consecutive rounds of the cipher. More precisely the authors state their motivation (section 7.4) ...

Prompted by Paŭlo's comment, I took a look at the original requirements set out for the AES candidates. A useful page for that turns out to be AES - The Early Years (1997-98) on the NIST web site (and surprisingly hard to find there; the internal links are broken and Google doesn't find it either). The AES key lengths were specified in the original Request ...

During the final round of the AES contest, NIST issued a summary of the 5 finalists on the topics of security, speed, implementation, and such. That sounds like what you're looking for, see sections 3 and 5 of the paper. General ideas from the paper: Rijndael had a potentially lower security margin than Twofish and Serpent. Rijndael had better performance ...

About the best you can do is have a master public/private key pair where the public key is stored on your server and the private key is stored offline. When you generate a new private key, encrypt it with the master public key and store that in the database. That way, if a password is ever lost, you can recover the user's private key by using the master ...

AES always has a blocksize of 128, and a keysize of 128, 192 or 256 bits, because NIST only standardized those modes. Rijndael on the other hand is more flexible regarding parameters. Wikipedia says: AES has a fixed block size of 128 bits and a key size of 128, 192, or 256 bits, whereas Rijndael can be specified with block and key sizes in any multiple ...

I'm assuming there are holes in your question, but I'll answer it as is and then you'll probably want to change the question. Although please also see this question as it might answer your question too. The probability of decrypting an AES encrypted ciphertext is $1$ if you have the right key and (practically) $0$ if you have the wrong key. This is ...

There are two well-known distinguishers of reduced-rounds version of AES based on integral cryptanalysis. The first one is a 3-rounds distinguisher from Daemen and Rijmen while the other is a 4-rounds distinguisher from Gilbert and Minier. The 3-rounds distinguisher relies on the fact that one byte $y$ of the state in the third round is the xor of four ...

It has to do with how the key schedule generates round keys (see my answer to your other question). Each round key is 128-bits in AES (or the number of bits in the block size for Rijndael). So if you have a 192-bit key, the key schedule picks a subset of the key bits for each round. Repeat that for 10 to 14 rounds (depending on key size) and you will use all ...