Reputation
26,464
Next tag badge:
411/400 score
78/80 answers
Badges
2 36 109
Newest
 Revival
Impact
~398k people reached

Jun
25
comment what are the most common stream ciphers algorithms?
I think you mean Salsa20 (a family of 3 stream ciphers Salsa20/8, Salsa20/12, Salsa20/20) rather than ChaCha20 (the 20-round version of ChaCha), since ChaCha was published in 2008.
Jun
25
comment Why is HMAC-SHA1 still considered secure?
There seems to be a confusion in the question: HMAC-SHA1 is not used for signing a document (at least, not usually; and assuming it was, the standard assumption for HMAC that its key input is secret can't hold since the signature verification procedure is public). I find that answer quite fine.
Jun
25
comment Implementing AES MixColumns with fewest XOR gates
@RFuentess: AES decryption is much less common than AES encryption, because AES tends to be used in CTR mode (sometime OFB or CFB, and for authentication CBC-MAC) which all use AES encryption only (including during decryption); not coincidentally, AES decryption is unavoidably slower and bigger than encryption. That likely explains why AES decryption was not coded. $\;$ I'm not the author or otherwise related to the nice code that I linked to; I only highly recommend it as the theoretical basis of a compact 8-bit implementation.
Jun
23
comment Attack for RSA 1024 bit with Low Public Exponent
@poncho: Great, that's what I was attempting in 5, done the right way, that I missed entirely! You nailed it!! I'll update the answer.
Jun
23
comment Attack for RSA 1024 bit with Low Public Exponent
@poncho: Had the same idea but you beat me on publishing first!
Jun
23
comment What is the danger if a non-prime is chosen for RSA?
The question is very similar to this one. To summarize my answer: if it accidentally happened that we use a composite, most likely the RSA key pair would fail on first use (in a PKI: when the certification request is checked, thus thus wrong key would not get certified). Another option, so unlikely that the combination of bad luck and a hardware defect is not enough to cause it, is that it was picked a Charmichael number instead of a prime, in which case RSA will work.
Jun
22
comment What are the differences between collision attack and birthday attack?
@HeatfanJohn: Yes. In crypto we often use the approximation that a birthday attack on a fair hash of $n$ bits succeeds with odds near $1/2$ after $2^{n/2}$ hashes (if we are able to detect any collision that might occur). $2^{64}$ is 19% lower that the more precise estimate that you quote.
Jun
22
comment Implementing AES MixColumns with fewest XOR gates
Could not immediately locate how I got my formula, but I dug here nice public code that I know works, with aes_mixColumns_invusing 21 XORs and 9 table lookups of a single table (or 7 table lookups of two tables). That seems to beat the Lightweight MixColumns paper on all counts. I did not use exactly that in my own code because lookups are slower than XOR, extra tables waste space, and it uses a temporary that I manage to avoid.
Jun
22
comment Implementing AES MixColumns with fewest XOR gates
If I correctly read the formula quoted for InvMixColumns, it has (for each of four j) 23 byte XORs and 13 table lookups of two different tables (or 9 table lookups of three different tables). Some code that I have around has 25 byte XORs and 7 table lookups of a single table, the doubling table used in MixColumns. That seems preferable both in hardware and software for 8-bit gear. I'll try to dig where I got the equations, which seem better than those proposed in that Lightweight MixColumns paper.
Jun
22
comment Collision or second preimage for the Chacha core?
Sorry, my question is not about ChaCha (the cipher). I have now stated that explicitly. $\;$ I agree a lot about your praise of ChaCha (the cipher), as should be apparent in the info for the ChaCha tag.
Jun
21
comment Determine safety of exercise hash functions
@CodeInChaos: ah your reading makes sense and I rescind my former $h_{666}$. Your's is fine, and I immediately see no trivial attack against it in isolation. It's thus better than my idea of leaking $m$, going like: the right $218$ bits of $h_{666}$ are the left $218$ bits of ($m$ right padded with zeroes), the left of $h_{666}$ is some proper hash; which is not safe against first-preimage for messages up to $218$ bits, and $h_C$ inherits that weakness.
Jun
21
comment Collision or second preimage for the Chacha core?
@user3201068: indeed. I have now emphasized the (pre-existing) observation that a collision or second preimage for the Chacha core would not be a defect.
Jun
19
comment Device intercommunication with commands
Do you have two-way communication allowing a challenge-response protocol? Or a common variable reference (like a real-time clock assumed about correctly setup on both sides)? If not, do you have permanent re-writable memory (like EEPROM or battery-backed RAM, or a significant amount of Flash) on both sides? If not (or want to keep things simple), are you OK with being vulnerable to replay of former commands following a power-cycle of the controlled device?
Jun
19
comment A mathematical explanation of the DES encryption system
@esushi: +1 for the nice $\TeX$; I previously did not realize \newcommand was supported.
Jun
19
comment Concerns about use of MAC in my specification
The common cheat of using IV=0 cuts a corner on security. As example: assuming this and AES-128 in CTR mode, an adversary knowing a full block of plaintext at a fixed location in each message can test, with a single AES-128 encryption followed by a hash-table search, if a given key was used in any of the intercepted messages, which would not be possible with random IV. A match would allow to decipher one full message; that's a speed-up of some few orders of magnitude over brute force (likely not making the attack practical, especially compared to password enumeration).
Jun
18
comment Voting protocol - How many dishonest tallying centres can the protocol cope with?
Addition: the original source of the protocol is Nigel Smart's freely available Cryptography, An Introduction, with the protocol here. $\;$ Hint: the protocol uses Shamir's Secret Sharing in $t$-out-of-$n$ mode, which ensures that the correct tally can be obtained from the data published by any $t$ correctly-behaving tallying centers, where $t$ is a parameter less than the number $n$ of tallying centers.
Jun
17
comment An electronic voting system
@Mary Star: I did some level-1 spell-check. Nothing immediately struck me as obviously wrong. Sorry I have no time to do more within the next days, like explaining the algebra (the easy part is to show that if everyone is honest, the equations are met; I don't think a correct argument can be made that if anyone without super-polynomial computing power cheats, that's detectable, if you account for real-life threats including rigged hardware). Good luck for your exposé. $\;$ I do suggest that you make a step aside, and wonder if all that is desirable in the world we live in.
Jun
17
comment How to quickly detect incorrect password in encrypted file without compromising security?
I'm glad that your problem seems solved, but I do not understand how if you use RNCyptor's Password-based encryption: the validator in RNCyptor (draft) v4 does NOT much help to quickly check if the password is correct. It does save computing HMAC, but except for very large packets or small PBKDF2 parameters it is not a significant time saver, since the running time is dominated by the stretching of PBKDF2, which (as apparent here) must be performed before the validator check.
Jun
17
comment How to quickly detect incorrect password in encrypted file without compromising security?
Ah, so likely you are talking about RNCyptor (draft) v4. In the password mode, my reading is that checking a password using the validator still requires the expensive password-entropy-stretching with PBKDF2 (which BTW is far from state of the art, we have scrypt giving orders of magnitude more stretching)
Jun
17
comment What is search space?
Hints: you are asked to give a close (upper) estimation of the number of possible $B$ (and take the base-2 log of that if the answer is wanted as n bits). $\;$ Examine the chain of dependencies from $A$ to $B$, and the number of possible values at each point. $\;$ An alternative way to look at it is: how many values are produced by the fastest algorithm that produces all the possible values of $B$?