Thomas

2,589 reputation

1320

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

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

summary answers questions tags badges favorites bounties reputation activity

599 Actions

suggestions reviews revisions comments badges posts accepts all

16h	comment	how many bit flips current computers can carry per second? When brute force is hard? There was a discussion about iterating through a 256-bit counter a while ago on this question. The DES cracking hardware can bruteforce a $2^{56}$ key (which is a lot more than just flipping a bit) in a matter of hours, so I'd say $2^{64}$ bit flips per second would not be unrealistic for resourceful agencies. The question is somewhat narrow, though.
1d	comment	What key length is required to keep simple keyed “hash” secure? Property 2 calls for a sufficiently long key such that brute force is inapplicable. Property 1 requires a nonlinear pseudorandom mapping such that given any number of previous input/output pairs, the attacker cannot predict the output of any new input with probability better than $1/n$ where $n$ is the number of possible outputs. That's how you would define a "poor" and a "good" mapping. Limiting to one-to-one is very bad for property 1, since any new input/output pair simplifies the attacker's job as he can rule out one extra possible output.
1d	comment	What key length is required to keep simple keyed “hash” secure? Most of those mappings are crap. Any selected key should give rise to a "good" mapping. And, yes, the key should certainly be large enough to prevent brute-forcing, else someone could try all possible keys and check that they work with a few inputs and outputs. Can you state which security property you are interested in? (what should an attacker not be able to do)
2d	comment	How to calculate cycles per byte @LucaDelGiudice Just noticed the "hash" tag. If you are measuring the performance of a hash function, you want to use messages longer than 16 bytes, otherwise most of the time will be spend doing initialization/finalization work (which do take up a lot of clock cycles for most hash functions). Try a 32MB buffer, you should see better results.
2d	comment	How to calculate cycles per byte @LucaDelGiudice Maybe the algorithm you are using has not been optimized during compilation, which would explain the slow speeds you see. But without additional details it's hard to tell.
2d	answered	How to calculate cycles per byte
May 12	comment	Can someone help with the following hashes? Hash != base conversion and does not belong in the same sentence as "decode"
May 11	comment	Now that quantum computers have been out for a while, has RSA been cracked? [citation needed]
May 10	comment	Cryptography based upon neural networks @mikeazo en.wikipedia.org/wiki/Neural_cryptography it apparently exists, though I've never heard of it either. Sounds like it would be more appropriate to cryptanalysis than the actual process of using cryptography.
May 9	comment	Does knowledge of original file size provide a cryptographic weakness? As for the original question, standard cryptography assumptions make no effort to conceal the original file's size. It may be desirable to do so in some situations, and it can be done to some extent, but in your case it seems unwarranted.
May 9	comment	Winzip AES256 vs PGP Secure for what, against what?
May 8	comment	Solving a discrete logarithm using GDlog @benmuell Click the checkbox left of the answer (and upvote it :-))
May 6	comment	Show that for all integers n>2, n does not divide n^2+2 I.. just don't know what this has to do with crypto. Other than the approach suggested by CodesInChaos, I would simply observe that since $n^2$ is a multiple of $n$, the next multiple of $n$ is $n^2 + n$, and for $n > 2$ we have $n^2 < n^2 + 2 < n^2 + n$ so $n$ cannot divide $n^2 + 2$ (this is basically the same thing, but perhaps worded more intuitively)
May 5	comment	how much is secure to encrypt a password using itself (as encryption key) for storing it on a unsecure media? This would normally be correct but the OP stated his requirements, namely that only AES was available on the target platform (this is a very real limitation on embedded systems) - see Henrick's comment.
May 5	comment	What's the difference between AES and earlier block ciphers? @SmitJohnth But a "non-cryptographer" would not use raw ciphers.
May 5	comment	What's the difference between AES and earlier block ciphers? @SmitJohnth The distinction blurs as you move to a higher level. Ultimately most cryptography libraries provide a unified interface to all encryption algorithms regardless of the cipher being used, asking for the plaintext, IV, and key, and returning the ciphertext, and handling all the differences internally, away from the user's concern. The only difference with stream ciphers is you need some more work as they typically don't have built-in IV mechanisms and sometimes not even key schedules, but that can be abstracted away as well.
May 5	comment	how much is secure to encrypt a password using itself (as encryption key) for storing it on a unsecure media? However this may not be valid depending on your needs as it is somewhat malleable (but then, so is your scheme to some extent).
May 5	comment	how much is secure to encrypt a password using itself (as encryption key) for storing it on a unsecure media? See Thomas Pornin's answer here, AES has issues with related keys and so should not be used in this context. If you really must do this, I would suggest encrypting a 16-byte constant instead and using that to check. The attacker will get a plaintext-ciphertext pair for free, but that should not be a problem provided the rest of your cryptographic scheme (if any) is designed properly (without these types of constraints). Preferably, use this "key" only for authentication.
May 4	comment	Is AES really used for Top Secret stuff? @Romain Unless they have found a cryptanalytic attack on AES, no amount of GPU clusters will succeed at brute forcing AES with our current understanding of information theory. As far as we can tell, AES is strong when used properly. Whether governments or secret agencies use something else is by definition pure speculation and somewhat off-topic.
May 2	comment	Encrypt a single file, chunk-by-chunk, each chunk using different key (AES) You should mention this is for a school project in the original question. I was led to believe this was for a real application (you said "Android application").