# Tag Info

0

Standard security proofs for CTR and CBC deal with pseudo-random permutations (or pseudo-random functions). Relevant references can be found in Sections 4 and 5 of Rogaway's survey. However, it is unclear what you mean by a proof with random permutations. Where is the key then?

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 ...

2

You are correct in that after the birthday bound you will leak some plaintext in random 8-byte blocks. Nova's answer has the specifics and links to useful sources. To give you a rough idea of the risk, you can look at what percentage of the data could leak. 10 TB is about $2^{40}$ blocks. The expected number of collisions is $2^k (1-(1-2^{-n})^{2^k-1})$, ...

3

I didn't find anything about the exact way Crashplan encrypts files, only that it uses Blowfish in CBC mode. The block size of Blowfish is 64 bit, so there are $2^{64}$ different input blocks and the same number of output blocks. All in all $147573953$ terabytes of different output data. The problem with this is the birthday attack. Summarized it says that ...

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), ...

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