568 reputation
413
bio website codingrobots.com
location
age 31
visits member for 3 years, 3 months
seen Aug 10 at 10:54
Programmer and founder at Coding Robots

May
2
comment A single password manager vs password generator/hash
@AdamSmith It is assumed that salt is a public value: usually password generators use site address for it, e.g. PBKDF2("master password", "google.com"). If the salt is secret (let's call it a "secret seed", because salt is reserved for a different term) and has enough entropy (e.g. 128 bits), then it's infeasible to guess the master password. However, this is not the scheme discussed here (deriving many passwords from a single one), as the user has to remember a random value along with the master password for it to work.
Apr
29
comment A single password manager vs password generator/hash
@AdamSmith the difference between bruteforcing/running dictionary attack on encrypted password database and a hash of the generated password is only in the cost of the hash operation. E.g. if password database is encrypted with a key derived with PBKDF2-HMAC-SHA256 with 100,000 iterations and the password generator generates passwords by running 100,000 iterations of PBKDF2-HMAC-SHA256, and a website that leaked passwords uses bcrypt to hash passwords, then guessing the master password for password generator (bcrypt(PBKDF2-SHA256(master_password))) is only harder for the cost of bcrypt.
Mar
31
comment Single-purpose symmetric encryption scheme for single files
@StephenTouset no, it uses MD5. See github.com/Chronic-Dev/openssl/blob/master/apps/enc.c#L552 and openssl.org/docs/crypto/… or stackoverflow.com/questions/9488919/openssl-password-to-key. Also, the output format doesn't seem to be documented.
Mar
30
comment Single-purpose symmetric encryption scheme for single files
Have you seen the file format of scrypt utility? It's a good reference on how to do it properly: code.google.com/p/scrypt/source/browse/trunk/FORMAT
Mar
30
comment Single-purpose symmetric encryption scheme for single files
@StephenTouset proper key derivation?
Mar
13
comment Security of tokenization of plain text conversations - cryptanalysis
See also crypto.stackexchange.com/questions/3645/…
Mar
9
comment ChaCha cipher + Poly1305
I think you're referring to hashing the result of DH. djb says you should hash the result of curve25519 scalar multiplication before using it ("Both of you can then hash this shared secret and use the result as a key for, e.g., Poly1305-AES." cr.yp.to/ecdh.html), so crypto_box uses HSalsa as a hash function for shared key. Crypto_secretbox doesn't have this step.
Mar
8
comment ChaCha cipher + Poly1305
HSalsa is used to turn Salsa20 (8-byte nonce) into XSalsa20 (24-byte nonce) as per "Extending the Salsa20 nonce" paper: cr.yp.to/snuffle/xsalsa-20081128.pdf
Jan
26
comment Hashing passwords with a salt - why use different salt for everyone?
Again, the question was: are there drawbacks in the system where we don't use /dev/urandom to generate salts? I listed them. I'll try to rephrase my answer.
Jan
26
comment Hashing passwords with a salt - why use different salt for everyone?
This answer to a bit different question on Security StackExchange is very good: security.stackexchange.com/questions/11221/…
Jan
26
comment Hashing passwords with a salt - why use different salt for everyone?
I considered the case of changing passwords later in the answer. We get system which leaks some information about passwords if there are multiple leaks of database. Is it bad? Yes. Is it better than a single per-database salt? Yes. Is it worse than random salt? Of course.
Jan
3
comment Needing to encrypt plain sight information
@Andrew User1 can give away decrypted plaintext without revealing any keys anyway. Perhaps, you can tell us what kind of problem you're trying to solve?
Jan
2
comment Needing to encrypt plain sight information
Encrypt content with a randomly generated key. Encrypt this key for each user with a user-specific key.
Jan
2
comment Needing to encrypt plain sight information
Use TLS + server-side user authentication.
Dec
27
comment Future-Proof Versioning and Validation
@andrewcooke I see what you mean. If you're worried about this, don't tell users to update software, make "this is incorrect packet" the only kind of error. It hurts usability, though.
Dec
27
comment Future-Proof Versioning and Validation
"But that means that if someone maliciously alters the version then they can "trick" the code into aborting." If they are able to modify "packets", then they already can trick your code into aborting in any case by sending garbage or holding packets to make receiver believe that sender didn't send anything.
Dec
11
comment Deriving Keys for Symmetric Encryption and Authentication
If your key has 256 bits of entropy and your key derivation function is one-way, adding or removing iterations to key derivation won't make bruteforcing particularly harder or easier -- 1 iteration is already hard enough. Iterations are needed when you're dealing with passwords, which don't have enough entropy.
Dec
11
comment Can I use PGP to sign a message without providing cryptographic non-repudation?
@AJHenderson thanks, the answer looks more clear now.
Dec
10
comment Can I use PGP to sign a message without providing cryptographic non-repudation?
@AJHenderson DH is not asymmetric encryption, but it's an asymmetric algorithm. If we have two classes -- symmetric and asymmetric, where would you put DH? Certainly not symmetric.
Dec
10
comment Can I use PGP to sign a message without providing cryptographic non-repudation?
"With asymmetric cryptography, the sender is not able to encrypt it such that the receiver could have encrypted it without disclosing a private secret." This is incorrect: en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange