Reputation
33,823
Next tag badge:
95/100 score
20/20 answers
Badges
2 50 137
Impact
~560k people reached

Mar
18
comment Concatenation of two strong hashes may have striking weakness
Yes, that's simplest (thus better) than what I had in mind! $\;$ Can the last part of the question be so conclusively answered?
Mar
18
comment Concatenation of two strong hashes may have striking weakness
The definition of the HAC is: "preimage resistance — for essentially all pre-specified outputs, it is computationally infeasible to find any input which hashes to that output". There is no notion of finding the original message, or that it is short. The given is a random element among possible hashes (or is it the hash of a random thus presumably huge message). If we concatenate good independent hashes (like SHA-256 and SHA-512 truncated to 256 bits), we obtain one that is much more resistant to that than the originals.
Mar
18
comment Concatenation of two strong hashes may have striking weakness
@Nova: My first statement was indeed wrong. However I'm not sure that I agree with your proof. I've been making the same proposition, and have since prudently backed out. Exactly what definition of first-preimage resistance are you taking? Find preimage for a random element of the destination set, or find preimage for the hash of a random unknown element of the source set? Or is it a random unknown element of some subset of the source set?
Mar
17
comment What practical uses can random hash collisions be put to?
Congratulation: you have built a machine to give a random solution to the first preimage problem, which can trivialy be turned into one generating collisions. Here is a variant of your machine: it can tell that the number you typed is also the SHA-256 of the ASCII string Password
Mar
17
comment Resynchronizing brute-force attack against stream ciphers
Searching the first 32-bit or 64-bit segment of known keystream into the candidate keystream while it is generated can be done at very little cost, if that's engineered into the software (or hardware) generating the candidate keystream; the rest of the search is more costly, but rare, thus has little impact on performance.
Mar
17
comment Resynchronizing brute-force attack against stream ciphers
Ah, so that attacker knows synchronized ciphertext-plaintext pairs, thus some of the true keystream. Is there anything problematic with just searching the chronologically first such known keystream segment in each candidate keystream corresponding to candidate keys, and in those few where it appears soon enough, computing more candidate keystream and search the other known keystream segments, in order to confirm the candidate key?
Mar
17
comment Resynchronizing brute-force attack against stream ciphers
Can we liberally interpret "know the general structure of the underlying plaintext" into all plaintext bytes have high bit clear? If yes, hint: that's choosen-enough plaintext. $\;$ If no, please clarify what the quote allows.
Mar
17
comment Resynchronizing brute-force attack against stream ciphers
Is the stream cipher in the question strictly exclusive-OR of plaintext with a single large keystream (or is it a more complex protocol)? $\;$ Also: can the attacker mount a chosen-plaintext attack? If yes, hint: do this with a plaintext that does not require re-synchronization.
Mar
17
comment Signature constructor using Self-signed certificate
As always, the signature in a self-signed certificate is adding nothing to security (its main virtue is avoiding to create two data formats, one for uncertified public keys, the other for certified public keys). The first scenario is fine if you trust https, including its many sub-definitions, parameterization, and that no adversary has control of any trusted CA.
Mar
16
comment CCA-attack is possible in RSA, but how the decryption key $d$ is known to anyone
In RSA, except for side channel attacks, there's no known way the decryption key $d$ (or some equivalent information) can leak, no matter how disastrous the padding or the attack model, including CCA.
Mar
15
comment Why does consecutive permutations or consecutive substitutions not enhance security?
@PaŭloEbermann: a public/unkeyed permutation/substitution is not, by itself, safe. It can lead to safety of a cryptographic algorithm embedding it (and that's the context of the question). In that context, for some permutation/substitution and cryptographic algorithm, iterating the permutation/substitution can increase safety, as illustrated in the second paragraph of my answer. While the example detailed is contrived, I could construct a natural one, with a simple public/unkeyed permutation/substitution increasing security when iterated.
Mar
15
comment Why does consecutive permutations or consecutive substitutions not enhance security?
I disagree with the answer, which as written would allow to wrongly conclude that 3DES is no safer than DES, on the grounds that 3DES is 3 times DES performed in sequence and is a permutation (or substitution) since DES is one. $\;$ Also I'm reading the question as about the different assertion that iterating the same permutation (or substitution) does not increase security (which is wrong).
Mar
15
comment RSA key pair generation and FIPS 140-2, 186-4
@user1563721: sorry, I pass at interpreting FIPS 140-2 rules applied to PKCS#11 certified tokens to guess what form of private key export remains possible.
Mar
13
comment Key exchange using hash function
In (b), Alice generates a public/private key pair and sends the public key to Bob by email; Bob chooses a symmetric key k; Bob encrypts k using Alice's public key and sends the cryptogram to Alice by email; Alice deciphers that using her private key and thus gets k. That's how Alice and Bob share the symmetric key k, in the absence of attack. $\;$ In (d), Bob additionally reads H'(k) to Alice over the phone.
Mar
13
comment Of what use is my code for finding prime numbers of a certain size?
In Mathematica, RandomPrime[{$i_\text{min}$,$i_\text{max}$}] gives a pseudorandom prime number in the range {$i_\text{min}$,$i_\text{max}$}.
Mar
10
comment Encryption scheme that allows compare ciphertexts based on the clear text
I re-tagged that question as about order-preserving encryption. This answer might help.
Mar
10
comment Fault encryption attack on RSA
Do we have any information about what bit is changed, in particular if it lies in the public exponent, or the public modulus?
Mar
10
comment what is the current actual budget - as of 2015 - needed to build a DES breaker machine?
+1 for RIVYERA, which previously had not blipped on my radar.
Mar
9
comment How do SignRecover and VerifyRecover work?
@sfallahdoost: I added my references; I admit they are not crystal clear, and some of implementing PKCS#11 requires experience in the field.
Mar
6
comment Is there a format preserving cryptographically secure hash?
@sashank: If $P\to C=E_K(P)$ is a block cipher of 128-bit block size and key size assimilated to a random oracle implementing a random permutation for each $K$ (e.g. AES-128), then $P\to H(P)=E_P(P)$ is a plausible 128-bit hash that preserves the length of the original string. I'm reading Ricky Demer's comment as using something on that tune.