Reputation
26,609
Next tag badge:
419/400 score
79/80 answers
Badges
2 37 113
Newest
 Nice Answer
Impact
~412k people reached

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 How HMAC.Update function works?
@Acetylator: Notice that if/when Key is longer that the block size (64 bytes for SHA-1 and SHA-256, 128 bytes for SHA-512), the hash of Key (rather than Key extended to a block when Key is smaller than a block) shall be used as K. $\;$ Independently: some implementations deffer initialization of H2 until Final, instead keeping K (or K XOR OPAD) for this purpose; this avoids multiple active instances of the hash, which typically conserves memory.
Jun
17
comment How to quickly detect incorrect password in encrypted file without compromising security?
I do not see that this RNCyptor solves the problem of fast check for incorrect password in its password variant (or that it can be done). Incidentally, there's a funny security near miss in rnc_isEqualInConsistentTime, supposed to compare the equality of bytestrings of variable length with resistance to timing attack: if self.lengthwas 256 (or a multiple of that), then empty otherData would be a match. It does not degenerate into a security problem in the context, since we do not use 2048-bit MACs.
Jun
16
comment How HMAC.Update function works?
I don't see that it makes sense to pass a key to HMAC.Update, and neither of your references does. Equivalent uses HMAC.Init('key'); HMAC.Update('abc'); HMAC.Update('def'); Result1 = HMAC.Digest and HMAC.Init('key'); HMAC.Update('abcdef'); Result1 = HMAC.Digest seem more logical to me; and then I do not get what you ask.
Jun
16
comment An electronic voting system
@Mary Star: hopefully your latest comment is now addressed in the second paragraph of the answer.
Jun
16
comment An electronic voting system
@Mary star: standard terminology is that the signing algorithm of X can only be run by X; in the sentence you quote, X is the voter and the signature is made by the the voter (using hardware she or he trusts), not by the voting centers (which are not individually trusted). How a voter is supposed to trust said hardware is beyond me (because that's my area of expertise, contrary to most people promoting electronic voting, which area of expertise tends to be politics or sales).
Jun
16
comment Is the HMAC construction really neccessary for a fixed length message?
I do agree that HMAC is technically superfluous when the hash is Keccak/SHA-3 (perhaps subject to padding key to a sponge step). $\;$ I do not adhere to the HMAC criticism: there are plausible defects in compression functions that do not open to attack in Merkle-Dåmgard hashes for their definition of security (collision, preimages), but open to attack in H(Key||Data) for fixed-size data (I tentatively exhibit an example in the last paragraph of my answer); HMAC masks these defects well; and I see no definitive argument that SHA-256's compression function does not have such defect.
Jun
15
comment Is the HMAC construction really neccessary for a fixed length message?
@eBusiness: read the last paragraph again! I exhibit a hash that is just fine (when the desired properties of the hash are collision-resistance, first preimage resistance, and second preimage resistance) according to your own "if it's not broken, then it's fine" line of thought ; but such that I effortlessly break the MAC constructions in the question according to the standard definition (that you give). $\;$ Beside, your reasoning does not invalidate my "rather be safe with a proof than sorry with an attack that surfaces" attitude.