1,485 reputation
1416
bio website
location Madrid, Spain
age
visits member for 1 year, 7 months
seen 9 mins ago

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
Jul
16
answered Questions about BCrypt and PBKDF2
Jul
12
answered Review of AES encryption concept for an open source project
Jul
12
comment IV and Headers inside cipher text
@Thomas if that's the case, then sure, although I don't think it's good practise. The only reason I can think of to store the hash of a key with ciphertext would be to verify a correct key at decryption time. However, if the encryption is authenticated (which it should be) either by a dedicated AEAD mode, or with a MAC, then a hash of the key seems redundant. Does storing a hash of the key with ciphertext serve some other purpose?
Jul
11
comment IV and Headers inside cipher text
If by key hash you mean the actual key, then no, of course it can't be transmitted and/or stored with the ciphertext. If that's not what you mean then please clarify. The IV, however, can be stored/transmitted with the ciphertext, as it's not required to be secret. You might find a few minutes on wikipedia enlightening.
Jul
5
answered A block cipher with independent keys for each round
Jul
4
comment Fast Salsa20 in java?
@Nuoji - yup, it took me a little while to figure it out too, but check out the original documentation as the naming conventions are quite consistent. In the Salsa20 class, you'll find the function crypto_stream_xor. Simply pass in the output buffer c (ciphertext), input buffer m (message), mlen (number of message bytes to be processed), n (8-byte nonce), noffset (0 if you're using Salsa20 and not XSalsa20), and k (256-bit key). Salsa20 test vectors are here.
Jul
3
comment Fast Salsa20 in java?
I can't testify as to it's speed, but this java version of NaCl contains an implementation of Salsa20 (and XSalsa20). Give it a try.