Hot answers tagged brute-force-attack
30
256-bit key cracking through exhaustive search is totally out of reach of Mankind. And it takes quite a lot of wishful thinking to even envision a 128-bit key cracking:
trying one key must be reduced to the flip of a single logic gate (compared to the hundreds of thousands which are actually required);
that gate must be more energy-efficient than the most ...
15
There is some Thermodynamic Limitations. A good explanation about Thermodynamic Limitations is by Bruce Schneier in Applied Cryptography:
One of the consequences of the second law of thermodynamics is that a
certain amount of energy is necessary to represent information. To
record a single bit by changing the state of a system requires an
amount of ...
14
Assume that 1 evaluation of {DES, AES} takes 10 operations, and we can perform $10^{15}$ operations per second. Trivially, that means we can evaluate $10^{14}$, or about $2^{46.5}$ {DES, AES} encryptions per second. This is a simplistic view: we are ignoring here the cost of testing whether we found the correct key, and the key schedule cost.
So on our ...
13
Yes, a computationally unbounded attacker can break any public key system.
One easy way to see this is to consider the KeyGen algorithm, which takes takes as input a value R (which in normal use is the output of some random number generator), and outputs a public key PK and a private key SK.
Now, what a computationally unbounded adversary can do is ...
12
The average cost for electricity in the US is $\$0.12$ per kWh. For a single server I'll use 3741 kWh annually as an estimate. That would be about $\$450$ per year for one machine.
Let's say you can do $10^{14}$ decryptions per second. That is $3.15*10^{21}$ decrypts per year for one machine. You need to do (on average) $2^{255}$ decryptions in a year, so ...
11
From the perspective of someone who is a non-cryptographer but runs penetration tests against, well, anything really, there is a very simplistic answer that is generally correct in the real world:
Assuming the implementation of the encryption algorithm is not flawed (I know, not always a good assumption, but the common open source tools get a lot of peer ...
8
If (you suspect that) the (plaintext of the) encrypted data is ASCII text, you can check if the high bit of each decrypted byte is zero. As long as you have more than 24 bytes of data to check, the odds of that happening by chance are pretty low (given that you have a 24-bit keyspace).
UTF-8 text is also pretty easy to detect, since all bytes that do have ...
7
This is called ciphertext-only cryptanalysis*, and it's pretty difficult unless the cipher is quite weak. Therefore, the first priority for a cryptanalyst in such a situation is usually to try to find more information about the algorithm. Fortunately (for the cryptanalyst), as Kerckhoff's principle suggests, there are often ways to find out how the ...
7
Assuming the n-bit CRC of an unknown bit string b is known, one can constructively rebuild any consecutive n bits of b from the rest of the bit string (and the definition of the CRC). Indeed, in the case described, that speeds up password search considerably. One can compute the last 32 bits of the password (likely, 4 characters) from the beginning of the ...
6
Yes, having two valid keys in effect halves the size of the keyspace — from 2256 to 2255 possible keys per each valid one.
Not to 2128 keys, which is what a 128-bit keylength would get you.
Remember that the number of possible keys grows exponentially with the number of bits per key. (Adding one bit doubles the size of the keyspace, since the added ...
6
The last major effort I know of for cracking keys was the Distributed.net effort.
You can find the project page at http://www.distributed.net/RC5/en. In 2002, they cracked a 64-bit RC5 key using at total of 331,252 computers over 1,757 days. Their maximum throughput was "equivalent to 32,504 800MHz Apple PowerBook G4 laptops or 45,998 2GHz AMD Athlon XP ...
6
It's not possible.
The number of primes smaller than $x$ is approximately $\frac{x}{\ln x}$. Therefore the number of 512bit primes (approximately the length you need for $1024$ bit modulus) is approximately $\frac{2^{513}}{\ln 2^{513}}-\frac{2^{512}}{\ln 2^{512}} \approx 2.76×10^{151}$.
The number of RSA moduli (i.e. pair of two distinct primes) is ...
6
Despite the impracticalities of using a 43-char password, I would say yes, such a long password would be secure when hashed with just SHA256. Assuming 127 possible ascii characters, a password of 8 characters would require an attacker to search about 2^56 possibilites (viable), whereas a password of 43 characters would require searching about 2^300 ...
5
The classic way to do this is to have all parties commit to individual random values by publishing a secure hash of a suitably random-nonce-padded number. Once the commitments have been distributed, the parties open the commitments by publishing the nonce and the number. The numbers are combined in some previously agreed suitable fashion such as adding them ...
5
For ElGamal to be secure, the 'discrete log problem' (which is, given $g$ and $g^x$, find $x$) must be intractable. You give a generic way to attack the discrete log problem for a group with $n$ elements with something like $n$ steps (I say about because your approach isn't the simplest version of this type of attack; the simplest does take $n$ steps); ...
4
Well, from your previous questions, I'm assuming that your writing a utility to brute-force decrypt a password protected file (encrypted with a certain encryption utility), and you're looking for a way to determine whether your trial decryption is plausible.
Normally, when an attacker attempts to decrypt something, he has some idea about what it is (why ...
4
Non-technical brute force method:
The most cost-effective "brute-force" method I can think of is to hire a gang of mobsters to force the guy who knows the password into giving it up. For a guy with no security, a good mobster would probably cost about \$5,000, and you'd need at least 3 of them. If you are going for a high-profile guy, a good mobster would ...
4
Ok, here is one possible sketch of a brute-force style attack against OCB, which doesn't assume you know the nonce. It takes 512 trial decryptions for every key tested, so it's a bit more expensive than, say, a brute-force attack on CBC, but only by a constant factor.
Let us assume that:
you have an encrypted message that is $16n+15$ bytes long
that you ...
4
Moore's law has several variants. Gordon Moore himself first put it as a double of transistor density every year (i.e. you could put twice as many transistors on a given wafer surface, and production cost increases linearly with the wafer surface). In 1975, Moore altered his law to a double every two years. However, putting more transistors in a given ...
4
A service that provides such numbers is called a random beacon.
Since everyone has to agree on what a beacon's value is and peers may not have a complete view of the network, it is very difficult to construct a universally verifiable value using only internal network data. Since data only becomes canonical when it is included in a block (a block that is ...
4
There is no AES-512; AES takes keys of 128, 192 or 256 bits.
When encrypting with a password, there are two steps: first the password is converted into a key for the symmetric encryption, then the encryption is applied. Brute force can be applied either on the password (enumerating all possible passwords until a match is found) or on the key itself ...
4
I'll assume that "sha256hmac" designates HMAC using SHA-256 as the underlying hash function.
HMAC is used for its intended usage: the first parameter privatekey is a key, I assume random and secret, of fair length (128-bit); the second parameter word is a (possibly public) message; output is a (possibly public) cryptogram. Observing any number of (word, ...
4
Instead of that home-grown scheme, I would use PBKDF2 instead if you simply are sold on the idea of iterated hash schemes. It uses an such a scheme, although not exactly the one you have described, and is well-studied and considered secure.
However, PBKDF2 doesn't offer many advantages over bcrypt, as PBKDF2 is still vulnerable to GPU and FPGA/ASIC ...
3
A constant salt (or not using any salt) allows to do the same brute-force or dictionary attack on many passwords at once, instead of only at one at the same time. So you'll get an earlier "first match", and more matches at all for the same amount of work.
If the attacker wants a specific user's password, it is not faster at all (other than allowing ...
3
I don't believe it's quite as simple as Ilmari is making it out to be, although his end result that "it doesn't really damage the security" is quite correct.
It is easy to see that Ilmari's answer is actually a worse case; the attacker manages to run the same attack on both keys simultaneously, with negligible cost over running the attack over one key. It ...
3
A DES cracker just tries out keys until a matching key is found.
So, with Verilog, you design a circuit which includes:
a counter, which enumerates possible keys in a fixed order;
a DES encryption engine, which, given a plaintext block and a key, computes the corresponding ciphertext block;
a comparison engine, which compares the ciphertext block obtained ...
3
The usual assumption is that the attacker knows a full plaintext block; that's what the EFF DES-cracking machine uses. That machine knows exactly 8 consecutive plaintext bytes and the corresponding ciphertext block; it stops when it finds a matching key. Since there are 256 possible DES keys, and 264 possible 8-byte blocks, chances are high that there is ...
3
The brute force technique described in the question is hopeless, as pointed in this other answer.
However there are much better techniques to attack RSA keys, including GNFS. Therefore 1024-bit RSA keys, even though they offer sizable security, can no longer be considered entirely safe from predictable academic efforts, or even safe at all from ...
3
Why can't you simply ask the person who made that file to tell you the password?
No one knows how to decode an AES-encrypted file, such as password-protected WinRar files, without knowing the password.
As far as we know, the only way to decode AES-encrypted files is to somehow obtain the right password, and then use that password to decrypt the file.
In ...
3
Is this a good idea?
Not really.
It is rare to find attacks against vetted designs that allow a complete break with a tiny amount of cipher-text.
Assuming you plan to have a unique key (which isn't used anywhere else) for just this few kilobytes of plaintext, it's very unlikely any cryptographic attack could be mounted against any modern cipher that ...
Only top voted, non community-wiki answers of a minimum length are eligible
