# Tag Info

5

Well, that's simple: $2^{64}/2^{30}$ is indeed correct. And since $2^{64}/2^{30} = 2^{64 - 30} = 2^{34}$ then that would be the answer. A simple recalculation would give you approximately 545 years. As you can see, 64 bits is pretty much on the border of being cracked by general computers. Brute force basically scales linearly with the amount of keys. ...

6

Why is 128-bit encryption considered good enough for medium term security only? Because in the long term it is expected that mankind will be able to carry out $2^{128}$ operations because it's not physically as impossible as $2^{256}$ operations. Quantum computing or brute force attack? Assuming quantum computers work at a speed comparable to ...

1

We solved this problem in just 9 hours 37 minutes. Here is how to do it. Tools you need: sudo apt-get install cryptsetup sudo apt-get install dh-autoreconf sudo apt-get install libcryptsetup-dev 1 - Dump the encryption header of your device using cryptsetup toolset, here /dev/sda1 was our device yours could change: sudo cryptsetup luksHeaderBackup ...

1

To my current knowledge, the content of a Zip 2.0 file is likely safe for a week, assuming the password has large entropy (>95 bits; 16 random characters among uppercase, lowercase and digits qualify, and will work with most pkzip-2-crypto-compatible unarchivers); with 64 bits, I would not bet the house against a determined adversary with a large FPGA (or ...

0

The PKZIP legacy encryption is a stream cipher with a 96-bit state. From this answer about the possibility of brute forcing an encrypted archive Baring hypothesis change or progress in some of the above, it is inconceivable that the original file data can be recovered from the archive using anything remotely comparable to the computing effort that a GPU ...

1

I just stumbled on http://www.tomshardware.com/reviews/password-recovery-gpu,2945-5.html. Although it's a bit old, it does give me some perspective. It mentions ~30 million password tries per second on a Zip 2.0 file. So if someone had a that can perform 10 times as much tries per second, they would need (6^5)^5 / 300 000 000 = ~94767626766 seconds = ~3000 ...

0

While an eight digit search space is easily iterated, the default settings for LUKS/cryptsetup use a password hash that takes 1s to compute (PBKDF2-SHA1 with iterations chosen to reach that time). That means a brute force of eight digits would take $10^8/60/60/24$ days or over three years on that hardware. If you assume a GPU is ten times as fast, you will ...

0

I think the attack models establish constraints on the cipher parameters that allow you to confirm guesses in a brute force or probabilistic search. A simple way to look at it is that they let your write equations involving the cipher parameters. For example, in $c = enc(p,k)$, you can fix two of the parameters and solve for the third. Clearly $c$ ...

2

TL;DR: 64-bit entropy is nowhere near enough against a serious attacker. Yes, you have calculated the worst case correctly. Your second calculation isn't about rainbow tables, but about a full hash table. Now for "how long can you stop a serious attacker" if you hash a fully random 8 byte string with SHA-256. If the attacker has enough money, they can ...

3

My question is whether one can start with both a secret and a string - representing ultimately a share in the end state - and work his way into finding the rest of the shares? With $t-1$ shares and the secret, you can uniquely reconstruct the polynomial (and with that, generate all the rest of the shares, assuming you know their $x$ coordinates). With ...

Top 50 recent answers are included