meta user
network profile
| bio | website | codingrobots.com |
|---|---|---|
| location | ||
| age | 30 | |
| visits | member for | 1 year, 9 months |
| seen | May 17 at 11:14 | |
| stats | profile views | 7 |
Programmer and founder at Coding Robots
|
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? @JesperMortensen bruteforcing attacks against sufficiently large random strings (e.g. 16-32 byte) are infeasible. They apply to passwords because they don't have enough entropy. Your attack fails at step 2 if you don't know the "secret global salt" (which should be properly called "a key") if it has e.g. 128 bits of entropy. Of course, stealing this key is probably just as likely as stealing database. I'm just pointing out that your attack as described doesn't work. |
|
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 26 |
comment |
Hashing passwords with a salt - why use different salt for everyone? @StephenTouset I'm not suggesting that it's a usable scheme. We're on Cryptography StackExchange, where we discuss a lot of theoretical stuff; otherwise we might as well replace the whole site with the page that says "use NaCl for encryption and scrypt for key derivation" ;) |
|
Jan 26 |
comment |
Hashing passwords with a salt - why use different salt for everyone? In 2 you have a pretty big assumption. It's infeasible to bruteforce a long enough "shared salt" if it's random and the hash function is good. |
|
Jan 25 |
comment |
Hashing passwords with a salt - why use different salt for everyone? Assume for a moment that we use a PRF with a single 32-byte randomly generated secret key in counter mode as PRNG for salt: PRFk(0) for the first user, PRFk(1) for the second user, etc. Take HMAC-SHA-256 as PRF. Rename secret key to "global salt". Replace counter with unique user id. Take scrypt as password stretching function. Is scrypt(password, HMAC-SHA-256(globalSalt, userId)) a sound password hashing scheme? |
|
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. |
