Hot answers tagged

9

$s_i = s_{i-1}\cdot(N + 1) + 1 = s_{i-1} \cdot N + s_{i-1} + 1$ but $s_{i-1} \cdot N = 0 \pmod N$, so $s_i = s_{i-1} + 1 \pmod N$ which means you can discover the next number to be generated just looking to the current one...


8

There is no such thing as a 16 bit AES key. AES is a block cipher with a block size of 128 bits and a key size of 128, 192 or 256 bits. As a block cipher, AES can only encrypt 16 bytes (128) bits at a time. AES in itsef is not (CPA) secure as repetition of the plaintext would lead to repetitions of the ciphertext. To encrypt larger amounts of data, AES ...


5

Yes, the attack you sketched out would work - in theory. In practice, it's an efficient (computable in polynomial time) mapping $\psi:E\rightarrow\mathbb Z_n$ we're lacking. As for the unefficient mappings, $\psi:x\cdot P\mapsto x$ would be perfectly fine theoretically, but we don't know how to calculate it (it's the elliptic curve discrete logarithm ...


4

See Vitor's answer for the answer your professor was looking for. However, for any PRNG of the form $s_{i+1} = F(s_{i})$, where the attacker sees the $s_i$ values, and knows $F$, then he can distinguish it. Given a sequence of values $r_1, r_2, ...$, he can determine whether it was generated by that PRNG by checking if $r_2 = F(r_1)$; this is always true ...


3

This is not a concern; the model of costs that the paper uses is unrealistic. In the paper, they state: In other words, the attacker is given unlimited amount of time in preparation (Section 2, second paragraph) That is, they assume that the attacker can easily spend $O(2^{128})$ time (or more, if necessary) to generate a Hellman table (or Rainbow ...


3

Our goal is to find a root $(x_0,y_0)$ in $\mathbb{Z}_e$ of the polynomial $f(x,y) = x(A+y)-1$. Finding roots of a polynomial in any $\mathbb{Z}_n$ isn't an easy job, in order to solve the problem Coppersmith had the idea to reduce to problem to finding a root $(x_0,y_0)$ over $\mathbb{Q}$ of some other polynomial $f'$ related to $f$. About Coppersmith ...


2

Scheme is not IND-CPA for any message longer than one block. I'll include a image of CBC mode below for reference (Source: Wikipedia). Suppose instead of block cipher encryption we have plaintext xor-ed with the key as you propose. You'll note that for message block 1, $M_1$, the ciphertext block $C_1 = M_1 \oplus IV \oplus Key$. Similarly $C_2 = M_2 ...


1

The attack, as stated in sections 6.2 & 6.3, actually can only recover the quantity $K_1[1,3]\oplus K_2[1,3]$. What you would hope to do is, to use a similar approach via another high probability linear relation [usually there is more than one] and recover more relations between subkey bits. Eventually, the goal is recovering all the original key bits. ...


1

Probably you could also read "known best attack" instead of "best known attack". In that case the attack would simply be the attack that reduces the security the most. This is often calculated in powers of two, represented by bits. For instance an attack could reduce security from 112 bits to 80 bits. If a second attack only reduces security from 112 bits ...


1

I recommend you will read a bit about chosen-plaintext attack. If the scheme you are using is CPA-Secure then even when an adversary is choosing two different plaintexts, giving them to the challenger and then the challenger picks one of them, encrypts it and sends it back to the adversary - the adversary won't have an efficient algorithm to find out which ...


1

Here is how I would approach this: First off, strip off the unkeyed parts of the cipher at the beginning and the end. That is, process the plaintexts with the 'rotr 8/add/rotl 3' at the beginning, and process the ciphertexts with the 'xor/rotr 3' at the end (rotr because we're working the inverse direction). Next, we focus in on only the right side ...


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


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



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