5,700 reputation
11428
bio website github.com/CodesInChaos
location Frankfurt, Germany
age
visits member for 2 years, 8 months
seen 11 hours ago

12h
comment Are there maximum allowed key size in USA?
Nowadays the main restriction is that you need to notify some government institution before exporting strong crypto and tell them what you use. There used to be restrictions on the key size to 40 or 56 bits, but that never applied to AES since it was only developed after the restrictions were lifted.
12h
comment Random token and email confirmation key of 10 chars sufficient?
You can still include the id, but with properly random 120 bits the probability of guessing them is very small, even with a huge amount of requests. But as always in cryptography this depends on a correct implementation and it's easy to screw it up without noticing it.
12h
comment Random token and email confirmation key of 10 chars sufficient?
If you have 120+ bit tokens you don't need to include the id anymore. Just make sure you generate them from a secure and well seeded PRNG, not crap like rand, mt_rand etc.
12h
comment Random token and email confirmation key of 10 chars sufficient?
If the email confirmation link does not contain the email address or userid, it'd be possible to generate an account with an email you don't own with about a billion requests by first requesting a token a billion times and then guessing a token a billion times, after which you probably guessed correctly once. (A kind of birthday/multi target attack)
12h
comment Random token and email confirmation key of 10 chars sufficient?
10 chars (60 bits) is a bit on the low side, but there is no reason to use more than 20 (120 bits).
2d
comment Length-constant password comparison in scrypt?
Scrypt itself has far worse timing issues internally. Unlike timing issues with comparison those might actually give an advantage to an attacker in some situations.
2d
comment FIPS 140-2 C# Password Hash
On a more practical side, it's recommended to use 16 byte salts and you should not output more than the output size of the underlying hash (20 bytes in your case, since it's based on SHA1), else the attacker gets a speedup but the defender does not.
Apr
20
comment How secure is to seed PRNGs with the sequences from CSPRNG?
Seeding a CSPRNG or stream cipher from /dev/random is secure. If you never reseed you don't get recovery from state compromise, but that's not very useful in the first place. Another potential issue is that many stream ciphers can be run backwards, so you can recover earlier state and output if you know the current state. This is important for forward secrecy, but of little relevance to games.
Apr
17
reviewed Approve suggested edit on What makes it illegal to use the information learned by exploiting a bug?
Apr
17
reviewed Approve suggested edit on What makes it illegal to use the information learned by exploiting a bug?
Apr
17
comment What makes it illegal to use the information learned by exploiting a bug?
You certainly can't send a heartbleed exploit packet by accident during normal use of the site. So I'd consider the legal risk pretty high, especially if it's done repeatedly to the same host in order to learn information.
Apr
16
comment What happens if biometric data is stolen?
Biometry can only be used as local authentication. Since it's not secret, it relies on the presence of trusted hardware which can tell apart a fake piece of hardware for real fingers/eyes/etc.
Apr
15
comment Brute-Force/Dictionary attack against encypted file using PBKDF2 key derivation
28 bits of entropy in a password isn't enough, even with several million iterations.
Apr
15
revised Brute-Force/Dictionary attack against encypted file using PBKDF2 key derivation
edited title
Apr
15
reviewed Approve suggested edit on Brute-Force/Dictionary attack against encypted file using PBKDF2 key derivation
Apr
14
comment If bruteforcing a password goes aaa, AAA, aab, AAB, etc, all the way to ZZZ, wouldn't ZZZZZZ be the most secure password?
That assumes that the attacker behaves like you proposed. What if they start with a random password, run until ZZZ jump to aaa until they're at the start?
Apr
14
comment Should service accounts be set to never lock out
I don't see any benefits for service accounts, you just need to configure them to use a strong password. So IMO the DoS risk outweighs the minimal benefits.
Apr
14
comment Are there “secure” languages?
The big problem with "don't use C" is interoperability with other languages. Pretty much any language supports writing a wrapper for C libraries. But you can't easily use say a Java library from C# or Python.
Apr
14
comment Encrypting passwords?
1) RSA is not useful here, since we need symmetric password based encryption 2) Picking an algorithm is easy, actually building something something secure from low level crypto like AES is hard.
Apr
14
comment Advantages of one time pad
For SSL you can use the MAC to see if you found the correct key.