21,390 reputation
12989
bio website
location Paris, France
age
visits member for 3 years, 3 months
seen 15 mins ago

I'm an engineer with experience in applied cryptography, in particular in Smart Card systems.


Nov
17
comment Key generation in Digital Signature Algorithm
One issue with the proposed algorithm is that the $p$ generated will often be $3071$- bit rather than $3072$-bit, a stated requirement. Also, as pointed by Henrick Hellström, if you want DSA per the U.S. Department of Commerce's book, then appendix A.1 is a must; also, following that procedure ensures the parameters are not cooked in some way; $p$ and $q$ essentially become nothing-up-my-sleeve‌​.
Nov
17
comment Why we can't implement AES 512 key size?
@Richie Frame: yes; on the other hand, odds of collisions for 100 billion devices each doing a million sessions are less than one in 68000; and good luck to detect (much less exploit) that device 12345678901 used the same key in its 654321th session as device 23456789012 did in its 765432th session; something tells me there are more serious threats lurking.
Nov
16
comment Block cipher to encrypt 8 bytes/64 bits - Use 64 or 128 bit cipher?
If you use a block cipher in ECB mode, the same plaintext will always lead to the same ciphertext, allowing to detect if the same plaintext is sent twice, which is against the security goals assigned to a cipher, and why good block ciphers operating modes use IVs. $\;$ Also: it would not be the first time when "requested to encrypt" should be understood as also requested to protect against malicious alteration. $\;$ Before choosing the block size of the cipher, find your goals, and what cipher or/and MAC or/and authenticated encryption you want to use.
Nov
16
comment What is the most computationally efficient way of generating pseudo-random permutations?
@user44353: You have found my intend! I fixed the typos that you kindly pointed. I'll provide a reference implementation in C and test values when time allows.
Nov
15
comment Why we can't implement AES 512 key size?
I have edited the answer to tone down the appreciation of AES-128 security. Still, if we re-key AES-128 every millisecond for thirty years, that's less than $2^{40}$ keys, and odds of hitting the same key twice are less than $2^{-49}$, an acceptable risk. However, if the same known plaintext gets enciphered with every key (as in CTR mode with zero rather than random IV), odds of finding one of the key with $2^{80}$ encryptions and searches in 16TB of data are $2^{-7}$, slightly worrying.
Nov
14
comment Why we can't implement AES 512 key size?
The paper that you found is vacuous to the point of being funny. The reference to an "ISO 3297:2007 Certified Organization" should act as a snake-oil warning, for this standard only defines the numbering of publications.
Nov
14
comment How can CBC-MAC be secure when message length is fixed?
The title of the question looks wrong to me; nearest logical substitute: How can CBC-MAC be secure only when message length is fixed?
Nov
13
comment Strange MAC algorithm
Somewhat related to this question. $\;$ Independently: knowing MD5(k||m) allows computing MD5(k||m||m'||m") for m' a certain known function of m and the length of k (with m' at least 9 bytes or 65 bits), and freely chosen m".
Nov
13
comment AES with weak keys
Yes. An easy statistical calculation shows that if for $j$ increasing from $0$ to $13$ we try the $128!/(128-j)!/j!$ keys with $j$ zero bits and $128-j$ one bits (using encryption of some known plaintext), we'll find a key with odds about $59.6\%$, and less than $2^{57.8}$ AES encryptions. With $j$ up to $8$, our chances to find a key are still a fair $9.7\%$, with effort less than $2^{40.5}$ encryptions. With $j$ up to $5$, $0.93\%$, with effort less than $2^{28.1}$.
Nov
12
comment Permutation parity after cycle-walking
@poncho: You are absolutely right! I misinterpreted the argument given in that answer into the (incorrect): any reversible transformation leaving at least 1 bit of the state unchanged is even. What's correct is: any transformation leaving at least 1 bit of the state unchanged and without influence on the other bits is even.
Nov
12
comment Permutation parity after cycle-walking
@poncho: I think you mean addition of a key as wide as the state, which does give balanced parity. Replacing XOR with modular addition in the combination of the round function output and half state does not.
Nov
11
comment How to perform frequency analysis of a substitution cipher using a Base64 alphabet
[Revised] Hint: How many letters, when present as first (resp. third, fourth, sixth) position of the plaintext generate a U (resp. O R S) in first (resp. fourth, fifth, eighth) position of the Base64? How does the expected frequency of letters in plaintext translate to expect frequency in first, fourth.. (resp third, sixth..) letter of the Base64? What about digrams in third and fourth, sixth and seventh.. position in plaintext and relation to digrams in fourth and fiveth, eighth and nineth.. position in the Base64?
Nov
11
comment How to perform frequency analysis of a substitution cipher using a Base64 alphabet
Note: UlVORk9SWU9VUkxJRkU= can't lead to k9U9VUJx=RWUOSkVUklR by character substitution. For example, the four U in the original are substituted with the different k, R, Oand l.
Nov
11
comment How big an RSA key is considered secure today?
@j.p. My article is about academic factorization records, and predates the article that you quote, which AFAIK did not lead to actual and public implementations. But yes, I will mention it.
Nov
11
comment How big an RSA key is considered secure today?
@Lembik: the curve would grow faster than linear (but, at least in the 2000 region, slower than what I show).
Nov
10
comment Are modified implementations of cryptographic algorithms a good idea?
Example: an apparently harmless modification of RC4 (that reportedly was used by a US government agency, most likely unknowingly), turns out to have a serious weakness that's not in the original.
Nov
7
comment Which attacks are possible against raw/textbook RSA?
Vast subject! Do you plan to answer your own question, or do you want others to dive in?
Nov
7
comment Franklin-Reiter related message attack m2 = a(m1)+b
Hint: if $v\in\mathbb Z$ with $\gcd(v,N)=1$, then $\exists w\in\mathbb Z, v\cdot w\equiv1\pmod N$. Such a $w$ can be efficiently found using (a slight variant of) the Extended Euclidian algorithm. That allows proper definition of $1/v$, then $u/v$, in $\mathbb Z_N$.
Nov
6
comment What is the most computationally efficient way of generating pseudo-random permutations?
@user44353: I concur with this comment, that 6 rounds of Feistel each one round of AES (implementable using AES-NI) in the round function, can be next to cryptographically secure (except for parity) for $18\le n\le 32$ as in the original question (but the devil lies in the details). Lower $n$ requires more rounds, (will think about how many). I don't know when cryptographic insecurity becomes a problem in your application, or what $n$ you need with your current round function (fair, but significantly lesser than an AES round).
Nov
6
comment What is the most computationally efficient way of generating pseudo-random permutations?
@user44353: I was only pointing the trivial: you must avoid that (((char)n_cipher)&0x7f)^key_aux[1] gets out of the range where the SBox entries are defined. That's either by filling all 256 entries or by limiting key_aux[1] to 7-bit. Which method is used is immaterial to the quality of each permutation, but the first option (your current one) widens the number of possible permutations (which is desirable) compared to 7-bit key_aux[1].