Tag Info

46

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

28

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

21

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

18

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

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

According to this source (also available as a graphic) and that raw data (see bottom right number), bitcoin mining nowadays (Feb. 2014) tops $20\cdot10^{15}$ SHA-256 per second, that is over $2^{79}$ SHA-256 per year. I'm guessing that a fraction of NSA's budget would allow this organization to do much better. Here is said raw data as a graphic. Renewed ...

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

10

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

9

XXTEA (also known as Corrected Block TEA) is a block cipher with $128$-bit key and block width parameterizable to $n\cdot32$ bits for $n\ge2$. It is an Unbalanced Feistel Cipher making $q=6+\lfloor52/n\rfloor$ passes over the block, with $q\cdot n$ rounds each modifying $32$ bits of the block. In Cryptanalysis of XXTEA, it is presented a chosen-plaintext ...

8

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

8

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

8

Not all ciphers can be broken, even by infinitely powerful adversaries. When used correctly, the One Time Pad (OTP) is information-theoretic secure, which means it can't be broken with cryptanalysis. However, part of being provably secure is that you need as much key material as you have plaintext to encrypt. Such a key needs to be shared between the two ...

7

I suspect that the meet-in-the-middle attack you have in mind is what is presented in this answer (or something similar). If so, then it's not actually correct to say "the only requirement is that the message be a product of 2 numbers of the same magnitude"; the message needs to be a product of two numbers of the same small magnitude. For example, the ...

7

How long are parameters used for? Usually $g$ and $p$ are kept static for a very long time indeed. In fact, the values to use are actually written in to standards. See here for an example. Those were values standardised ten years ago. So the answer is basically decades. The impossibility of brute force Let's suppose that I as an attacker decide I'm going ...

7

As long as you use a secure padding mode (i.e. -pkcs or -oaep, not -raw). The default padding mode for openssl rsautl is -pkcs (i.e. PKCS#1 v1.5), so you should be OK. That said, OAEP is recommended over PKCS#1 v1.5 padding, so you might want to use the -oaep switch.

7

There are multiple metrics for work or effort needed: Amount of operations it takes (one operations is, for instance, one invocation of hash function or number of modular multiplication operations) Amount of money it takes Amount of memory it takes Amount of time it takes Strength in bits Amount of operations Usually, if amount of operations is large ...

7

The XXTEA cipher is badly broken. Even though the paper is not published at a conference, the author verified it on reduced versions of XXTEA. You should never ever use a cipher or a hash function, that has been broken in academic terms, in particular if you are not a cryptographer. Attacks always get better, and a cipher does not attract much attention ...

6

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 ... 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 ... 6 The Bitcoin mining algorithm can not be simplified by exploiting any weakness in the SHA-2 hashing algorithm with the current state of the art. The problem is manyfold. From the SHA-256 point of view, there is no (partial) preimage search algorithm that applies to the full hash function. Even worse, the attacks that penetrate a fewer number of rounds have ... 6 I commonly hear statements along the lines of "all cryptograms are crackable - it's only a matter of time" Using a perfectly random key which is as long as the message itself, not a pseudo-random key, cannot be broken no matter how fast the attacker's computer is. This scheme is called one-time-pad and its security is guaranteed by information theory ... 6 As pointed in this comment, using a huge random key for a sound block cipher is an excellent defense to resist ASIC/GPU attacks. Each bit added doubles the effort required. If an adversary was able to build$10^{12}$ASICs each capable of testing$10^{12}$keys per second, odds of finding a 128-bit key by brute force running that for a decade are less than ... 6 It seems to me that what you need is a public-key signature scheme like rsa signatures. The process would work something like this: A user license$L$is created by your license generator Your system signs it to give$s(L)$and the licence is$\{L,s(L)\}$. When program tries to open the user's license$\{t,v\}$: The system verifies that$v$is indeed ... 6 A key size of 80 bits is the historical limit of infeasibility; that's what was used in the 1990s as a rule of thumb. That's the reason why Skipjack used an 80-bit key, and SHA-1 offers a 160-bit output. Various people have also estimated that a 1024-bit RSA, DH or DSA key offers an "80-bit equivalent" protection (see this site). One of the most optimistic ... 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 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 ... 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); ...

Only top voted, non community-wiki answers of a minimum length are eligible