8,839 reputation
12041
bio website github.com/CodesInChaos
location Frankfurt, Germany
age
visits member for 2 years, 9 months
seen 7 hours ago

Jul
28
comment Security of a 3-party key exchange protocol
@minar One problem with this description is that it doesn't describe what the parties do with the messages they receive. For example if the server validates that $S$ is in the expected place in the message then it can distinguish message 1 from message 3. It's also not clear to me why it'd be a problem if $S$ mixes up $I$ and $R$ since it'd still send them a proper session key. | Analyzing real protocols is certainly much nicer than analyzing underspecified theoretical protocols :)
Jul
28
comment Security of a 3-party key exchange protocol
Can the adversary communicate with S using their own identity E? If you combine that with an unauthenticated stream cipher as encryption you'd get another vulnerability.
Jul
28
comment Security of a 3-party key exchange protocol
What properties does your encryption provide? Is it authenticated encryption? Is it malleable? What about proper IVs?
Jul
28
comment Security of a 3-party key exchange protocol
do you really want k(I,R) in step 3? Or k(R, S)?
Jul
28
comment Cryptography used for login and signing transactions
Such short numbers point to symmetric crypto.
Jul
25
comment How random is the shared secret in the Diffie Hellman key agreement
I'm pretty sure that taking the 32 least significant bytes doesn't lead to noticeable entropy loss. Not sure about about the MSB.
Jul
25
comment Generating a secure random number in javascript
@user7676 Depends on the target security level, but somewhere between 100 and 200 bits.
Jul
24
comment What to watch for with openssl generating weak keys? (low entropy)
OpenSSL behaves properly if you use the right PRNG call. The other one is weak and using it doesn't just return bad data, it can also increase the time until the PRNG becomes secure. Unfortunately I forgot how the right call was called.
Jul
24
comment What to watch for with openssl generating weak keys? (low entropy)
The core misunderstanding here is that entropy can be depleted. If you seed a PRNG once, it can churn out practically unlimited amounts of secure pseudo random data. So the only time a good PRNG should block is after startup, until it has acquired 256 bits of entropy, and never after that (perhaps excluding weird events like forks, hibernation, etc.).
Jul
24
comment Ed25519 choice of private key implementation
I don't really get your question. Which different methods are you talking about? if you don't have any special requirements you should simply follow the spec, which derives the private scalar and a second key by hashing a 32 byte seed with SHA-512.
Jul
24
comment Why we must hash lot of times in rainbow tables?
@AbdelouahabPp I think you store the start and end of each chain. Possibly in some implicit form.
Jul
24
comment why hash(hash(str)) is bad?
@AbdelouahabPp If you hash passwords you should use a KDF with many rounds, not few rounds. Fast KDFs are useful if your master key is already strong.
Jul
24
comment Why we must hash lot of times in rainbow tables?
@Abdelou With some tricks you can compare the end of the chain with the hash you want to break so you know if the target hash can be a part of that chain. If it is, you recompute that chain from the beginning checking after each step.
Jul
24
comment Why we must hash lot of times in rainbow tables?
@StephenTouset This question is about hash chains in rainbow tables, a concept that isn't related to making a hash slow.
Jul
23
comment SIMON implementation, decryption issues
You wrote 196 in an error message where it should have been 192
Jul
23
comment Is there any weak message for an ECDSA signature?
@PaŭloEbermann DSA is very fast if you don't consider the (per-signature) pre-computation cost. You only need one multiplication and one addition after you learn the message.
Jul
22
comment How can I accomplish Key Derivation in JavaScript?
since salts don't need to be secret or unpredictable, only unique generating them shouldn't be a big issue. Apart from the fundamental javascript crypto problems(sending evil code etc.) the biggest practical issue is getting decent performance out of the js implementation.
Jul
22
comment Parallel-resistant proof-of-work scheme?
In practice on big problem is that once there are multiple task you can work on at the same time you can parallelize again. I found that most things I want to protect with proof-of-work allow many parallel jobs, even when a job is sequential by itself.
Jul
21
comment why hash(hash(str)) is bad?
If you're talking about password hashing then it's bad because it doesn't have a salt (which needs to different for each user) and it's bad because it's fast. Rainbow tables are largely irrelevant, what's the real threat are GPUs. Without salt all hashes in a database can be attacked at once, with salt they need to be attacked individually.
Jul
20
comment Is generating public key inevitably slow in classic Diffie-Hellman if the private key is large?
I think you can still choose a small value for x (say 256 bits) without losing much security even with a 3000 bit q. A large q is mainly problematic for DSA, not DH.