2,228 reputation
423
bio website touset.org
location San Francisco, CA
age 30
visits member for 1 year, 10 months
seen 10 hours ago

Cyclist. Rubyist.


1d
comment Key Derivation from random salted seed, HMAC and HMAC based KDF
@Hashed HMAC is not a magical construct that converts low-entropy inputs into high-entropy outputs. If the system RNG (e.g., /dev/urandom) is providing you with high-entropy randomness, there's nothing further to do. If you only have access to a low-entropy RNG (e.g., C rand), there may be nothing you can do; at absolute best, you can you use a key stretching algorithm like PBKDF2 or scrypt to linearly increase the effective cost of an attacker brute-forcing the key to simulate higher entropy.
Jul
25
comment Idea for user/pass hashing to prevent rainbow tables, would it work?
What advantage does this have over simply generating and storing a random value not derived from the user's password?
Jul
23
comment Which algorithm do you recommend for practical use to generate unique passwords for each website?
Use a password manager to randomly generate your passwords and store them.
Jul
4
comment Is SHA256 good enough to shrink a key?
Skein and Keccak do not have the thirteen years of cryptanalysis that SHA-256 has. There is little compelling reason to choose one of them over SHA-256 at the current time. There is no need to search for the NSA hiding under every rock.
Jul
3
comment AES256-GCM - can someone explain how to use it securely (ruby)
The auth_data is arbitrary contextual information (for instance, the database primary key of the encrypted message, or a username, or a string scoping the action to a specific "purpose") that must be provided verbatim upon decryption. It can be public, but it shouldn't be controllable by the entity providing ciphertexts to be decrypted. The auth_tag is the output of the authentication half of the cipher, and is what is used upon decryption to detect any changes to the key, ciphertext, IV, or auth data. It can be stored alongside the encrypted output.
Jul
3
comment AES256-GCM - can someone explain how to use it securely (ruby)
GCM absolutely does need an IV. The comment on that thread is that it doesn't need to be included as part of the auth_data.
Jul
3
comment SHA256 output to 0-99 number range?
Ah, I see. It only works in the event that the SHA-256 inputs are arbitrary. If you're hashing something out of your control (e.g., the contents of a file), there's nothing you can do.
Jul
3
comment SHA256 output to 0-99 number range?
@RossMillikan That still fundamentally doesn't work. It's just a more abstract approach to "distribute 36 special cases into 100 buckets".
Jul
3
comment SHA256 output to 0-99 number range?
Yes, you are still taking the remaining $2^{256} \equiv 36 \pmod{100}$ outputs and trying to distribute them equally amongst 100 buckets.
Jul
3
comment SHA256 output to 0-99 number range?
The OP is looking for a mechanism "where each number in 0-99 range is equally likely to be picked". The output of your algorithm is easily distinguishable from random, because some digits will be chosen more or less likely than the others due to aliasing introduced by converting to integers.
Jul
3
comment SHA256 output to 0-99 number range?
This only works if he doesn't require integers.
Jul
3
comment Is SHA256 good enough to shrink a key?
Since you have PBKDF2, you can also just do one iteration of that using both the keys as input, and the specified length as output. But SHA-256 works too.
Jun
30
comment Pi Message Encryption
@otus This doesn't really solve that issue anyway, since related-key attacks are trivial; even if you wanted to keep the spirit of this approach, you'd want to feed the output through a PRG anyway to avoid close keys effectively becoming two-time pads.
Jun
30
comment Pi Message Encryption
I agree. That said, I think it's important to be clear where this approach falls in the general spectrum of security. This approach will not likely benefit from repeating a cycle of pointing out weaknesses and "patching" them.
Jun
30
comment Pi Message Encryption
Even then, there are catastrophic flaws in the implementation. No use of initialization vectors. No authentication of the ciphertext. Operation on characters rather than bytes. This is something you might use to "encrypt" notes passed around in high school, and no more.
Jun
30
comment Pi Message Encryption
Any sane encryption algorithm shouldn't care about "characters" anyway. It should care about bytes.
Jun
30
comment Pi Message Encryption
This is a poor idea simply because you gain nothing by choosing an offset of $\pi$. Even assuming $\pi$ is unpredictably random, the "key" is the index of the starting digit of pi you wish to use, and to meet modern security expectations, it would need to be at least 128 bits long. But if you already have a 128-bit random key, you're done — you don't need to index into pi to get random digits!
Jun
26
comment Is it possible to get better randomness by using multiple PRNGs?
I must confess I took the assumption about being seeded from individual sources for granted; thanks for pointing it out! Actually, an even better example would be two identical PRNGs seeded from the same TRNG — they would produce the same bit sequence, and thus their XOR would be all zeroes.
Jun
26
comment Is it possible to get better randomness by using multiple PRNGs?
No need to do any kind of complex decision-making logic. Simply XORing PRNG outputs will do; at worst, the result has the same entropy as the most entropic of the inputs. For instance, if one of the inputs is truly random, and the other is completely attacker-controlled, the XOR of the two is still completely random and unpredictable to an attacker.
Jun
25
comment Using PBKDF2 twice with different argument order
You appear to have edited the response, but still only assert that $a = b$ is disastrous. How can an adversary subversively choosing their own password lead to the compromise of other parties' keys, as you claim?