hunter

558 reputation

bio	website
	location	Madrid, Spain
	age
visits	member for	5 months
	seen	55 mins ago
stats	profile views	5

	558 reputation	bio	website		visits	member for	5 months
19 badges		location	Madrid, Spain		seen	55 mins ago

summary answers questions tags badges favorites bounties reputation activity

124 Actions

suggestions reviews revisions comments badges posts accepts all

Apr 4	comment	How can mega store my login details and still be secure? Regarding "the password-hash and the symmetric password hash - Are they not the same thing?", assuming they are salted with unique values (as demonstrated above), then no, the resulting hash values are very different.
Apr 4	comment	How can mega store my login details and still be secure? @jduncanator "All I would need to do is bruteforce that MD5 and I would have the password used to encrypt my symmetric key". But how would the attacker know when the brute-force attack has been successful if they don't know what they're looking for? Regardless, if they're using MD5 as their hash algorithm, then they're not taking security seriously. Assuming they use an industry standard like SHA512 and a proper salt, then brute-forcing isn't viable (most people think sha256 is sufficient, and sha512 is overkill).
Apr 4	answered	How can mega store my login details and still be secure?
Apr 3	awarded	Custodian
Apr 2	answered	RSA digital signature vs authenticated cipher
Mar 29	awarded	Analytical
Mar 27	comment	How to choose between AES-CCM and AES-GCM for storage volume encryption Unless you have any special requirements, either would be fine. Both modes are approved by NIST. Personally I prefer the design of GCM. It's a bit more modern than CCM (EAX mode was proposed as a replacement for CCM). More specs on GCM here, and CCM here.
Mar 26	comment	Assymetric password encryption - Viable? Which algorithm? I think that last point from @fgrieu is the most important. I understand from the question that passwords need to be accessible in clear text (hence, they can't be hashed), but if they're encrypted and stored with the decryption key, then I don't see much value in encrypting them. However, I'm not very familiar with the authentication mechanism being used, so maybe there's something I'm missing.
Mar 22	comment	Could a very long password theoretically eliminate the need for a slow hash? Yep, I know where you're coming from - you make a good point.
Mar 22	comment	Could a very long password theoretically eliminate the need for a slow hash? Yeah, I suppose so. But as was made clear, this question was only ever in a hypothetical context, not a practical one. It's unreasonable to ask any user to remember and/or input a password of 43 chars, as such no user will use "123123123...".
Mar 21	answered	Could a very long password theoretically eliminate the need for a slow hash?
Mar 18	comment	How to use GCM mode and associated-data properly Anyway, I'm now clear on how to use GCM mode - thanks.
Mar 18	comment	How to use GCM mode and associated-data properly Sorry to be a pain in the a$$ but I was under the impression that salts (whether for hashes or KDFs) didn't need to be secret. Is there an advantage to keeping them secret?
Mar 18	comment	How to use GCM mode and associated-data properly the nonce must be kept secret? I've never used CTR or GCM mode in production, but I understood that it's similar to the IV in CBC mode in that it isn't secret, and can be prepended to the ciphertext in the clear. Is that incorrect?
Mar 17	comment	How to use GCM mode and associated-data properly As for GCM mode already incorporating any params that could affect the outcome of the decryption, if I use PBKDF2 to generate a key from a password, and the iterations and salt (may) change for each encryption, then changing them would obviously affect the outcome of the decryption. GCM can't automatically incorporate these params unless it knows about them, so is it right to assume that they should be included as associated data? Thanks for your explanation... I gather that the Associated Data param works like the 'info' param in HKDF.
Mar 17	accepted	How to use GCM mode and associated-data properly
Mar 16	asked	How to use GCM mode and associated-data properly
Mar 15	comment	BCrypt vs Key Stretching MD5 not an obvious reason, no. There are much, much stronger options which are quite commonplace, and not hard to implement. Look at the chart below; compared with PBKDF2 (using sha256, as below) key-stretching with MD5 and a similar number of iterations would be much weaker.
Mar 15	comment	What are the constraints for an IV using AES in CBC mode? For memory, the IV in CBC mode should not only be unique, but also cryptographically secure (as opposed to a mode like CTR, where the IV only needs to be unique). Would you consider the IV in this protocol to be CS? @StephenTouset 's suggestion to use GCM is good advice.
Mar 15	comment	BCrypt vs Key Stretching MD5 You mention the MD5 iteration count, but not the bcrypt work-factor - in terms of security, there's a relationship between the two. The (loose) recommendation for PBKDF2 using SHA256 (a much more robust hash than MD5) in 2013 is somewhere in the order of 50000 to 100000 iterations (and increasing exponentially), so 10000 iterations of MD5 doesn't seem very secure. For low-entropy input such as passwords, Scrypt is widely considered to offer better security than Bcrypt and PBKDF2. One disadvantage of Bcrypt is that the output length is not configurable.