Thomas

2,544 reputation

1320

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

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

summary answers questions tags badges favorites bounties reputation activity

368 Comments

suggestions reviews revisions comments badges posts accepts all

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").
May 2	comment	Encrypt a single file, chunk-by-chunk, each chunk using different key (AES) @tcboy88 Yes, the multi-keys idea is not really good. Having that many keys to go around is a huge gaping hole just waiting to be exploited. Just use a single key, use an encryption method which allows for parallel encryption (btw, I doubt even single-threaded encryption is slower than uploading your stuff to the cloud...) and use different IV's for each file. Much safer and easier than having to manage hundreds of keys.
May 2	comment	Encrypt a single file, chunk-by-chunk, each chunk using different key (AES) @tcboy88 The passwords are fine, it makes sense to separate passwords like this. However, for the integrity check, CRC32 is not good enough, and SHA1-256 (btw, that's SHA2, SHA1 is 160 bits only) is inadequate because you are letting the attacker find collisions which will break your integrity scheme. Better HMAC it with the cloud storage's key.
May 2	comment	Encrypt a single file, chunk-by-chunk, each chunk using different key (AES) @tcboy88 You don't need new keys for every single chunk. You can encrypt with a parallelisable algorithm (say, CTR) with the right IV and with the same key and then simply send that chunk. You'll be able to decrypt it when you get it back (even without other chunks, yes). But you need to store a MAC to make sure the chunk makes it back from the cloud intact (has not been modified by an attacker or simply damaged somehow)
May 1	comment	detecting ROT13/base64 encryption Not really, in my opinion. Encoding needs to be reversible, you need to be able to "decode" the encoded data back to the original data. But I suppose it could be argued that non-reversible processes could be called "encoding" in a meaningful sense (for instance, lossy compression).
Apr 29	comment	Custom crypto library in C @mikeazo Yes, with only network access it wouldn't be possible, I agree with you, though for handheld devices I would assume physical access is rather easy. But the question is quite vague on the intended threat model.
Apr 29	comment	Custom crypto library in C Or you could just use existing portable crypto solutions (yes, yes, there are some). By the way, using sleep() won't do anything against side channel attacks, an attacker will be able to distinguish the processor sleeping from the processor actually doing crypto work.