# Tag Info

2

AES-CTR is very appropriate. Since a credit card number is 16 characters long, it can be encrypted using a single 128-bit block without any encoding. You will only need 1 block, and hence not require a block counter, just the nonce. Depending on the amount of card numbers being stored, you would only need to store a portion of the full nonce. A 32-bit ...

2

swap-or-not seems perfect for your use case.

3

The reason NIST chose one algorithm out of the five AES finalists, even though all of them were pretty well-respected (and some were, at the time, considered likely to be more secure then Rijndael) is because NIST is a standards body, and the whole point of the AES project was to find a standard algorithm. The issue with approving lots of algorithms is that ...

1

Twofish and Serpent do not have any published non theoretical successful attacks (resulting in a complete break) so at this point in time they are considered secure. AES was chosen because the people making the decisions at NIST felt it made the best decisions (as far as the Rijndael spec goes) of making trade offs between security, speed, computing ...

2

Block ciphers map bit strings of fixed length to other bit strings of the same length. Hence, using only the block cipher primitive, you can't encrypt more than one block (typically 16 bytes), which is of course undesirable. The straight-forward (but bad!) way around this limitation would be to split up the message into chunks of block length and ...

1

Perhaps. You indicate this is from an embedded device. This strongly implies everything the device needs to decrypt it is already present in the firmware of the machine, including both the algorithm and the key. Here is a blog post on how a talented engineer accomplished a similar feat through reverse engineering. Note that this was not a cryptographic ...

3

As long as the IV is chosen correctly, every individual block of the encrypted output will be uniformly random over the set of all bit-patterns of the given size. Each block is independent from the clear text, but they are not independent from each other. The first block contains the IV itself, which by construction is uniformly random and independent from ...

7

In the first block, the IV provides the "randomness", and in subsequent blocks you just use the previous block of ciphertext instead. Based on the assumption, that the cipher is not weak and behaves like a pseudorandom permutation, this is basically the same: You XOR something unpredictable on the plaintext, and then encrypt. As long as the IV is chosen ...

1

This is why we use random initialization vectors (IVs) for all such algorithms.

4

All modern block ciphers are supposed to be pseudorandom permutations, meaning that they cannot be efficiently distinguished from a truly random permutation without knowledge of the key. (If a practical distinguisher were to be found for a particular cipher, that cipher would be considered broken by modern standards.) This also implies that no two secure ...

2

The alphabet size you need to consider, when calculating the unicity distance, is the size of the ciphertext alphabet. This follows from the definition of unicity distance, as the amount of ciphertext needed to rule out all but one of the keys.* For a classical cipher that only encrypts letters to letters, and ignores spaces and case distinctions, the ...

1

This technique is known as Ciphertext stealing. Ciphertext stealing avoids padding, but only works if the total message size is bigger than one block. Ciphertext stealing secure in principle, but as @mikeazo already pointed out using ECB and using 64 bit block ciphers is generally a bad idea. There are fancier length preserving encryption schemes. FFX mode ...

2

Yes there is a significant difference concerning brute-force. ECB suffers from multi target attacks whenever you encrypt the same message block. This is always possible in a chosen-plaintext attack and often possible in practice with a known-plaintext attack. With CBC the IV means that the plaintexts passed to the blockcipher are almost certainly unique ...

2

As Maarten Bodewes already wrote in a comment, if you ignore the computational overhead of XOR, then there is essentially no difference in CBC and ECB for a bruteforce attack. However, the question is actually mixing oranges and apples (and it is not obvious), because the security weakness of modes of operation has nothing to do with the underlying ...

-1

And here is a simple calculation time for brute force 56 bits DES key with a Laptop. Immagine your laptop execute one DES in $1 \mu s$, which is very optimist. To Explore the $2^{56}$ key space, it costs $2^{56} \; \mu sec$, which is approximativelly $0,72. 10^{17}\; \mu sec$. converting this quantity in hours, days and years, you need approximativelly \$2. ...

Top 50 recent answers are included