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

1h
comment RSA PKCS#1, v1.5 padding output
I was discounting the random bytes. I fully agree with your 11 bytes counting random in the standard case. The part I can't figure out in your answer is "the overhead may be a few bits more if your key has a different size than a multiple of 8"
3h
comment RSA PKCS#1, v1.5 padding output
My reading of the current specification of RSAES-PKCS1-V1_5-ENCRYPT is that the overhead is never more than 3 bytes. I'm counting $((n+7)\bmod 8)+17$ bits if the public modulus has $n$ bits. How do you come to the conclusion that it can be more?
7h
comment Is multiplicative blinding less secure than additive?
@Guut Boy: Yes. I'm willing to trade rep against ability to fix my past comments, but that's not an option, apparently.
9h
comment Compression in key generation of DES algorithm
@Abir: generic pseudocode: for j from 1 to 48 output[j] := input[pc2[j]]. Actual code will very much depend on language, array base index, representation of variables.
15h
comment Is multiplicative blinding less secure than additive?
Define multiplicative blinding; in particular how the blinding factor $b$ is chosen (its probability distribution); and how it is applied ($x\to x\cdot b$ is not the same as $x\to x\cdot b\bmod p$, the later form is just as secure as additive blinding when $x\ne0$ and $b$ is uniform over $[1\dots n-1]$).
23h
revised Common Modulus Attack not reproducible
Polish
1d
revised Common Modulus Attack not reproducible
Yet another link to introduce the reader to meadows
1d
revised Common Modulus Attack not reproducible
Link to public and relatively simple exposition on meadow arithmetic
1d
revised Common Modulus Attack not reproducible
Add link
1d
revised Common Modulus Attack not reproducible
Polish
1d
revised Common Modulus Attack not reproducible
Full problem statement
1d
revised Common Modulus Attack not reproducible
Contrast with other answers
1d
answered Common Modulus Attack not reproducible
1d
revised Compression in key generation of DES algorithm
Give alternate explanation
1d
answered Compression in key generation of DES algorithm
1d
comment Compression in key generation of DES algorithm
Anything wrong with the explanation and drawing in Wikipedia? Notice that in DES, the convention is that the bits are numbered from 1 onwards, with 1 being the first or left bit, or the most significant bit of in the big-endian translation to integer of a bitstring, or the most significant bit in the first or left octet in an octet string. Also, the output of PC2 is subdivided into 8 bitstrings of 6 bits (hence the presentation of the table as 8 lines of 6 entries), corresponding to S1 thru S8.
2d
comment Common Modulus Attack not reproducible
@Ricky Dememer: yes; you reduced the problem to finding an efficient way to compute the meadow inverse of a given $c$ modulo $n$ of unknown factorization when $c$ has no regular inverse, and is not $0$.
Feb
5
comment Security of RSA for paranoids with padding?
@Maarten Bodewes: no, I did not make any progress, or have had time to seriously explore potentially interesting alternatives to the dominant asymmetric crypto for Smart Cards (2-primes RSA, ECDSA per FIPS 186-4).
Feb
4
comment Secure blinding factor switching at malicious server-side (Switching in One Time pad)
@user153465: the second paragraph in the answer tries to address that. The adversary is free to compute any function of $v_1$ and $v_2$, like $v_4(v_1,v_2)=(v_1+v_2)^{v_1-v_2}$, or $v_3(v_1,v_2)=v_1\cdot v_2$, anything goes, that has no influence on the demonstration given. This is just extra added to the question's statement, obscuring it, that we want to get rid of to focus on the expressions involving $a$, or $z_1$, $z_2$ or other things not known to the adversary.
Feb
4
revised How does RIPEMD160 pad the message?
polish code comments