7

Will it be impossible to create ASIC for such algorithm? No, actually it is quite easy. The way you'd design a single brute-force core then is that you take a hashing engine for each hash function used, an input generator, a hash validator and a smart interconnect. Then when you want to brute-force an invocation of ordering 1, the input generator outputs ...


4

2048 bit RSA is currently and for the foreseeable future secure. 512 bit is currently not considered useful. 1024 bit RSA though not currently known to be cracked doesn't have enough security margins for comfort. Definitely not for securing $1B USD. Several years ago the cost of a machine which could break 1024 bit RSA in a year was a few million. Cost ...


4

You are forgetting that messages usually consist of many blocks and that many messages contain much more structure than just English text. For example an RSA private key will, when encoded, have a easy to distinguish header and will consist of many blocks of plaintext / ciphertext when encrypted with a block cipher. The same is true for Word documents, XML ...


4

A salt is supposed to be publicly available, for instance it needs to be stored in a DB next to the password hash. In that case the time it takes to recover the password is just a brute force or dictionary for the password. If the salt is static then rainbow tables may be used as well for any attack. Now if the password has an entropy of 256 bits then this ...


3

"brute force a PBKDF2-HMAC-SHA1" is not about collisions (at least, if a single hash is targeted, or if there's salt at the input of the password hash). It's a preimage attack. The hash output by SHA-1 is 160-bit. That's 20 bytes (not characters; these are different notions, and why we have character encodings). It can take $2^{160}$ values. The ...


3

Under an ideal cipher model, every key implements a random permutation. A random wrong key that maps $x_1$ to $y_1$ thus maps $x_2\ne x_1$ to a random ciphertext $y_2'$ other than $y_1$. For a $b$-bit block cipher, there are $2^b-1$ such ciphertexts, thus the probability that $y_2'=y_2$ is $1/(2^b-1)$. The probability that an incorrect key survives two tests ...


3

Most RSA implementations are designed to be run on 64-or-fewer-bit computers, so you won't have a huge disadvantage. However, if the key was randomly generated (with at least 128 bits of entropy), then your 64bit computer will not be able to crack it anyway. A 64bit computer can work on numbers of greater than 64bits by dividing the number into pieces. This ...


2

Brute-forcing an RSA key is basically impossible (AES uses a 128, 192 or 256-bit key, while RSA uses 2048, 3074, or 4096). That said, brute-force wouldn't be the attack of choice for RSA since the difficulty of breaking RSA is based on the difficulty of factoring a large semi-prime. Since most numbers aren't prime you have significantly less work to do... I ...


2

Usually, the brute-force attack is performed with known-plaintext where a message $m$ and its ciphertext $c = \operatorname{XTEA}(k,m)$ is available. Indeed, one may need more than one to exactly found the key since a key selects permutation and at the point $m$ there can be more than one permutation selected by different keys that maps to the same ...


2

Ok, it answer the specific question you asked: Bernstein says that it needs 640383 cycles for one multiplication Actually, when Dan talks about "multiplication", he is referring to a "point multiplication", that is, to the computation of $[n]P$ (given a large integer $n$ and a point $P$). In your simple-minded brute force search, you ...


2

This way the brute-force search space is reduced logarithmically. Well, no. If there are $N$ possible keys, then you test $N$ keys on the first byte. Then, you keep only those that succeed on the first byte, and test those on the second byte; that's approximately $N / 256^1$. Then, you test those keys that succeed on both bytes, that's approximately $N / ...


2

$4,294,967,296ops/4,000,000,000ops/s=1.07s$ $65,535ops/4,000,000,000ops/s=16.4μs$ 2GHz twice that. That's per-core. So 8 cores = 1/8 of a second or so. 64-core/128 thread 2GHz Threadripper = about 16ms. A GPU will be even faster. It's recommended to brute force the entire 2^32 space for testing various numerical functions, it's fast and catches all the edge ...


2

I have an Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz. Intel I7 has around 10 generations to speak of. The result cannot be accurate without providing the actual referenced Intel I7. Here is the method; Run openssl speed -evp aes-128-cbc command. That will give you the metric. My CPUs output: aes-128-cbc for 3s on 16 size blocks: 144516288 aes-128-cbc's in 3....


2

The answer depends on your definition of a hash function. In general hash functions don't guarantee, that they hide their input. A general hash function gives you three properties: preimage resistance (given $y = H(x)$ it is hard to find $x^*$ such that $H(x^*) = H(x)$) second preimage resistance (given $y = H(x)$ it is hard to find $x^*$ such that $H(x^*) =...


2

Brute forcing the key simply means iterating over all the possible keys, assuming you know the mode of operation (in this case CTR) and the IV. Then if a likely plaintext is found then you've found your key. It's always possible you find the wrong key, but the chances of you doing so diminishes with the amount of bits known of the plaintext. Usually you know ...


1

I cannot see why such values are required for AES-192 and AES-256. That's because you have a correct understanding of the situation, and the answer manual is wrong. Your analysis in "what I tried" is correct; there's not a whole lot I can add to it...


1

Brute force means running $2^{1024}$ operations. NVidia 3090 has $10496 \approx 2^{14}$ cores, each running at 1.70GHz which is approximately $2^{30}$ operations per second. Making the ridiculous assumption that a single clock cycle suffices for verifying a key, this comes to $2^{44}$ operations per second. Before going to $2^{1024}$, let's consider 128-bit ...


1

The generic hash collision is finding 2 different inputs $x$ and $y$ such that $H(x) = H(y)$. The cost of finding such a pair for a cryptographic hash function is $\mathcal{O}(2^{n/2})$ with 50% probability. For SHA256, the cost of finding a collision with 50% probabilit is around $2^{128}$. i.e. one needs to try $c_1 \cdot 2^{128}$ different inputs to find ...


1

First the obvious: for most common hashes, if $B$ is large (several blocks), and $C$ is empty or small, and $A$ is amenable to brute force search, it makes a difference if $\hat C=\text{Hash}(A\mathbin\|C)$ is known, because testing if a value $A'$ matches $\text{Hash}(A'\mathbin\|C)=\hat C$ requires hashing less material than testing if $\text{Hash}(A'\...


1

Typical attacks on Secret SPNs (i.e. with secret uniform S-Boxes) are integrals, see e.g. [1]. Even for AES: the S-Box is too good against differential/linear attacks (strong mixing in MixColumns is also necessary), so best attacks are of another kinds. (Not counting related-key attacks, which allow to deactivate many S-Boxes). More to the question: in some ...


1

Are such competitions held, and is there a recognized progress meter that is kept? No. It is generally believed that $2^{128}$ AES keyschedule and encryption operations are out of reach for just about anyone. If and when that changes and $2^{128}$ draws in to be a more realistic number perhaps people will do that. However, I have been unable to find any ...


1

Preliminary: the present answer assumes an Elliptic Curve group of order $n$ built on a prime field of order $p$, with one of $p$ or $n$ a 160-bit prime of the form in the question (rather $p$, which will give the most computational benefit, and is close to common practice). Choosing "public key $P$ as $p*G$ where $p$ is an Optimal prime" is not ...


1

…I could then brute-force all secrets which map plainchar[0] to cipherchar[0]. For the next character, I only need to try those passwords which succeeded for the first one. This way the brute-force search space is reduced logarithmically. Yes¹,². Problem is, ‘brute-force all secrets’ is supposed to be impossible in the first place. ¹ For a secure stream ...


1

XOR secret sharing used directly is unconditionally secure, if the randomly generated first share $S_1$ is a uniformly distributed vector in $\{0,1\}^{128}$. Let the secret be $X \in \{0,1\}^{128}$ and the shares be $S_2=X+S_1,$ and $S_1,$ where $+$ denotes bitwise XOR. For a third party to learn the secret, they need to brute force $O(2^{128})$ guesses in ...


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