Thomas

2,589 reputation

1320

bio	website
	location	Wellington, New Zealand
	age
visits	member for	1 year, 4 months
	seen	31 mins ago
stats	profile views	53

	2,589 reputation	bio	website		visits	member for	1 year, 4 months
1320 badges		location	Wellington, New Zealand		seen	31 mins ago

summary answers questions tags badges favorites bounties reputation activity

602 Actions

suggestions reviews revisions comments badges posts accepts all

Apr 15	comment	Correct way to truncate data to a range @chewsocks The mod operator is the problem. You are reducing 2^17 different values into disjoint equivalence classes of 100000 elements (namely 0 to 99999). Since 100000 does not divide 2^17, you have one equivalence class which is smaller than 100000, and therein lies the bias (in fact, one equivalence class will have only 31072 elements instead of 10000, those elements are twice as likely to occur as the others - hardly a uniform distribution). For 2^32 the bias is smaller, but still present. a mod m is unbiased iff m divides the range of a.
Apr 13	comment	Proper uses for CTR and CBC AES block cipher modes @Luke HMAC has the advantage of not needing an IV or anything, and is pretty much the standard when not using an authenticated mode (though again, it is not trivial to use correctly, even though it looks like it should be). I would recommend it if you have no exotic requirements and cannot use GCM/OCB/etc..
Apr 12	comment	Proper uses for CTR and CBC AES block cipher modes Encryption is a general solution and when done right doesn't care about the underlying structure of the data being encrypted. Consider that with CTR, you will need to add authentication yourself (perhaps using an HMAC) whereas OCB already includes that. Have you thought about that?
Apr 10	comment	Signature schemes for underpowered devices (8bit microcontroller) @brunosmmm Because threats are always underestimated.
Apr 10	comment	Given a certain entrophy per character, how long should a passphrase be to guarantee key strength? @PaŭloEbermann Indeed! Thanks for the correction.
Apr 9	comment	Ciphers in CBC mode reveal place of change in plaintext @mikeazo Done..
Apr 9	answered	Ciphers in CBC mode reveal place of change in plaintext
Apr 9	comment	Ciphers in CBC mode reveal place of change in plaintext Absolutely, every distinct message encrypted with CBC should (almost always) use a fresh new IV. Using the same IV for multiple messages is the number one cryptographic failure and while it isn't as devastating for CBC as for some other modes, it's still a major weakness. Still wondering, though, why is it important that the whole ciphertext changes if any one bit is changed?
Apr 9	comment	Ciphers in CBC mode reveal place of change in plaintext Yes, but using an IV you are already making sure two similar messages that start the same don't encrypt to the same ciphertext. And using a MAC (which I am confident you are doing) will let you catch any integrity (and/or authentication) failure, if you were thinking of using this as some kind of safeguard against transmission errors. Basically, my question is, why do you need this property?
Apr 8	comment	Given a certain entrophy per character, how long should a passphrase be to guarantee key strength? @Bas Yes. For this to strictly work, the passphrase characters need to be truly random and independent. Humans don't generate such passphrases, so you might want to give yourself a safety margin and add some more characters (or simply count in terms of words). Otherwise, yes, this is correct from the definition of entropy. Things are not always complicated :)
Apr 8	comment	May the problem with DES using OFB mode be generalized for all feistel ciphers Yes, but OFB only uses the encryption "blackbox", so it doesn't decrypt and encrypt repeatedly like you suggest. OFB doesn't need the decryption "blackbox" (just like Feistel ciphers don't need to be able to reverse their one-way $F$ function to work).
Apr 8	comment	May the problem with DES using OFB mode be generalized for all feistel ciphers "So, as we know using a feistel cipher has the nice property that running it twice through the cipher results back in the plaintext" not really, the subkeys are processed in the opposite order.
Apr 6	comment	Is there a preferred way/standard on how to transmit an initialization vector for AES encryption Plus, if you put it at the beginning, you can perform decryption as you receive the data, whereas you can't do that if the IV is appended at the end. Though this shouldn't be an issue either way since you need to MAC what you receive (you do use a MAC, right?)
Apr 3	revised	What's the difference between “HashX-512” and “HashX-1024”? corrected typo
Apr 3	answered	What's the difference between “HashX-512” and “HashX-1024”?
Mar 28	comment	Why are RSA key sizes almost always a power of two? Would you prefer key sizes of 818 bits, 1935 bits, 4144 bits? There is no cryptographic advantage, but using nice round numbers allows them to be more efficiently implemented and stored. It is also simpler, convention, and just makes more sense than apparently arbitrarily chosen key sizes. Also, 9000-bit RSA is overkill, people using such large keys are just wasting CPU cycles (and it's not "over 9000" anyway, so it fails in this respect as well ^^).
Mar 27	comment	Potential vulnerability in DH key selection - am I understanding this right? @Polynomial Doesn't "using Java's `Random`" count as a colossal vulnerability already? I think anything else short of handing over the secret nonce is moot in comparison. Good question nonetheless, timing attacks are very relevant currently.
Mar 25	comment	Where can I begin to study the math behind modern cryptography? Could you clarify "how computers simulates exact mathematical calculations"? Do you mean binary representation to store numbers? Cryptography rarely uses floating-point numbers.
Mar 23	reviewed	Approve suggested edit on reduces the coefficients of a modulo 3 on NTRU
Mar 22	comment	Could a very long password theoretically eliminate the need for a slow hash? "would" use, then. But even if the question was hypothetical, your entropy estimates do require the above condition (which I feel is important to state clearly, as this is a common question in cryptography), which is not achievable by humans (for instance, many people would use a sequence of words for such a long password, dropping the entropy to maybe 2-3 bits per character). Unless in the hypothetical scenario, humans are also robots, in which case fair enough. But no matter what humans choose, yes, ultimately such a long password would be almost certainly secure no matter what.