1,539 reputation
1416
bio website
location Madrid, Spain
age
visits member for 1 year, 10 months
seen 8 hours ago

Aug
19
comment OMAC/CMAC constant for different block sizes
the crypto++ implementation of CMAC specifies the constants for 64, 128, and 256-bit block sizes, if that's any help.
Aug
7
comment Allowing the user to choose the hashing formula at the registration
@CodesInChaos - oh really?? That's a terrible design decision. For encryption, the user can also choose between AES, Serpent, Twofish, and any (cascading) combination of the three. Do you know whether Truecrypt uses the same 'trial and error' approach to decryption? Definitely agree with you about increasing the PBKDF2 rounds, I think it's currently fixed at 1000 (nowhere near enough)... it doesn't make much sense to let users choose a hash algo, but not the number of iterations.
Aug
7
comment Allowing the user to choose the hashing formula at the registration
TrueCrypt allows the user to choose between SHA-512, Whirlpool, or RipeMD-160 as the underlying hash for PBKDF2. However, I believe the chosen algorithm is stored in the file header, so it would seem this option is just a user preference, as opposed to an increase of security through obscurity.
Aug
5
comment Achieving 256-bit encryption strength with PBKDF2 - HMAC-SHA1
@Ninveh - 4096 iterations of HMAC-SHA1 is far too few - in 2013 you should be aiming for somewhere around 100'000 iterations. Running the output through a hash function won't remedy this either.
Jul
31
awarded  Popular Question
Jul
30
awarded  Fanatic
Jul
28
comment Approaches to decoding data of an unknown type
You need to draw a distinction between encoding and encryption... they're quite different. Decoding an encoded string is (usually) trivial. Decrypting ciphertext without any knowledge of the algorithm/mode/padding/plaintext/key is generally not practical. Your question is far too broad - there are so many forms of cryptanalysis that you really need to start investigating them, and ask specific questions as they arise. Good luck!
Jul
26
comment Is truncating a SHA512 hash to the first 160 bits as secure as using SHA1?
@e-sushi ... thanks for explaining hex to me - I'm actually a web-dev too O_o. My point was that the OP's questions changes entirely if the hash were to be Base64 encoded (as an example). As such, it's helpful if people phrase crypto questions in terms of bits and bytes, to ensure that everyone is on the same page (so to speak). I know all those 1s & 0s are confusing for us simpleton web-devs, but I think it's important for anyone implementing crypto to understand basic concepts and terminology.
Jul
26
comment Is truncating a SHA512 hash to the first 160 bits as secure as using SHA1?
Just a note regarding terminology; hash output is in bits, not 'characters'. Your example above is hex-encoded (ie, 2 hexadecimal characters per byte), but that's just a representation... the underlying data is always in bits. You might consider editing your question to something like "truncating sha512 to the first 20 bytes...".
Jul
22
comment How can I accomplish Key Derivation in JavaScript?
@AbhiBeckert - yes, CodesInChaos is correct regarding the salt... it doesn't have the same stringent requirements as something such as in Initialization Vector (for example). Crypto-JS (link above) also provides functionality for random byte generation.
Jul
22
comment How can I accomplish Key Derivation in JavaScript?
I would go with the crypto-js implementation of PBKDF2
Jul
19
comment multiple keys via HKDF - whats better, one or two applications of HKDF-extract
thanks for the heads-up... I didn't know that.
Jul
19
comment multiple keys via HKDF - whats better, one or two applications of HKDF-extract
there's also a third option: similar to the first option, but expand once and request 256 bits of output, and split the output to make two keys
Jul
18
answered repeated use of HKDF-extract on the same PRK
Jul
17
revised Questions about BCrypt and PBKDF2
expanding answer based on further consideration
Jul
17
comment AES 256 Encryption - Is it really easy to decrypt if you have the key?
Can you give an example of a non-deterministic KDF? Your concern about IV-generation is valid - if the OP is using a static salt (ie, doesn't change with each encryption) and the KDF used to generate the key/iv is deterministic (I'm assuming it must be if it's being used to generate the key) then logically the IV would be static as well (big no-no). To avoid this, the salt should be refreshed with each encryption. ThomasPornin addresses this strategy in some detail here.
Jul
17
comment AES 256 Encryption - Is it really easy to decrypt if you have the key?
If the encryption mode (CBC) isn't known to the attacker, then ciphertext(s) of round block size lengths (16, 32, 64, etc) should be a pretty good clue.
Jul
17
comment Questions about BCrypt and PBKDF2
@GavrielFeria - BCrypt is slow by design, that's the point of a slow hash function... you talk about BCrypt being slow like it's an undesirable quality. Also, 64-bit block ciphers are not inherently insecure in all contexts, but aside from that - you certainly can't go around changing the block size of crypto algorithms and expect them to be as secure as the original design.
Jul
17
comment Questions about BCrypt and PBKDF2
@StephenTouset - agreed - assuming that's what the OP is proposing, which frankly, is a bit unclear... "10.000 iteractions of user's password with PBKDF2 and username (or email) as SALT and the server will store in the DB the salted SHA-512 digest of the PBKDF2 result". All the more reason to stick with a standard protocol.
Jul
17
revised Questions about BCrypt and PBKDF2
deleted 1 characters in body