9,854 reputation
12450
bio website github.com/CodesInChaos
location Frankfurt, Germany
age
visits member for 3 years, 3 months
seen 11 hours ago

Feb
28
revised DSA vs. ElGamal vs. Schnorr
edited tags
Feb
28
comment Frequency of letters change by the length of the texts?
There are two different effects: 1) For short texts the frequency won't be statistically significant unless you average over many independent samples 2) Different kinds of text use different words. For example the word frequencies you'd get from emails would be very different from those on wikipedia. It's very well possible that this shifts the frequency of letters somewhat.
Feb
28
comment Rfc2898DeriveBytes - password length
For those not familiar with .NET: Rfc2898DeriveBytes implements PBKDF2-HMAC-SHA-1.
Feb
28
revised Rfc2898DeriveBytes - password length
added 42 characters in body
Feb
28
comment Attacking both authenticity and secrecy in authenticated encryption modes
On x86/AMD64 CPUs "hardware support" means that the AES-NI instruction set is supported, which contains special instructions for AES and GCM (the latter can be used for binary field operation in general).
Feb
28
comment Non-standard signature security definition conforming ed25519 malleability
@Gracchus The expression $R < l - 1$ makes no sense. You can't compare group elements and scalars. Where in the paper is this?
Feb
27
comment Non-standard signature security definition conforming ed25519 malleability
@Gracchus What I listed is normal malleability. I assume you could run the same attack that hit MtGox by adding $l$ to $S$. If you want to use Ed25519 in a bitcoin like protocol, you certainly should add a $S<l$ check. Nightcracker's attack on the other hand is weirder, it certainly doesn't fit the common definition of malleability. I'm not even sure if we should classify it as an attack. (for details, see discussion on the github issue, I posted a longer comment overthere).
Feb
27
comment Designing a secure IM protocol
One obvious issue is that you can send a different message to each recipient with that scheme.
Feb
27
comment Non-standard signature security definition conforming ed25519 malleability
@Gracchus I only checked one implementation (Ref10, the most popular one), which accepts $s \geq l$. I.e. with this implementation Ed25519 is malleable. I expect most other implementations to accept those signatures as well. => You can't rely on non malleability unless you add additional checks yourself.
Feb
27
revised Non-standard signature security definition conforming ed25519 malleability
edited tags
Feb
27
comment Non-standard signature security definition conforming ed25519 malleability
@DrLecter For bitcoin doesn't matter if the real signer can produce distinct signatures. They obviously can with all ElGamal derived signatures, like ECDSA, Schnorr or EdDSA. But it matters if an attacker who doesn't know the key can take a signed message and modify any part of it, including the signature. Some implementations (e.g. MtGox) falsely relied on attackers not being able to do that, but the reference implementation doesn't suffer for these issues. See Transaction Malleability on the bitcoin wiki for additional information.
Feb
27
answered Non-standard signature security definition conforming ed25519 malleability
Feb
27
comment Non-standard signature security definition conforming ed25519 malleability
@DrLecter I suspect Gracchus wants to be sure EdDSA is not malleable, to avoid issues like the one that recently owned MtGox.
Feb
26
comment Can a properly implemented ed25519 private key with public underlying data be cracked?
@Gracchus No, don't pre-hash the message before passing it to Ed25519. Ed25519 already hashes the message, but in a way that's stronger than a normal hash. My example of additional signatures weakening the scheme is rather theoretical. My point is just that you can't make a generalized statement like ultraman's, you need to consider the specific scheme.
Feb
25
comment pbkdf2 password validation
For password hashes a constant time validation isn't that important, especially for attackers who don't know the salt. It's merely good style to use it. For MAC validation it's far more important, since a timing leak would allow construction of a valid MAC.
Feb
25
comment Strange Password Hashing
The technique for avoiding timing attacks doesn't work. So if the salt is known, it's just as vulnerable to side channel attacks as scrypt with known salt. At a glance this looks like a badly done variant of scrypt.
Feb
25
wiki created multi-prime-rsa description
Feb
25
wiki created multi-prime-rsa excerpt
Feb
24
comment Using ECDSA keys for encryption
Very similar to Using same keypair for Diffie-Hellman and signing
Feb
23
comment How has the “power” of cryptography evolved from its beginnings till today?
Nowadays crypto is all about designing higher level protocols, avoiding implementation mistakes, usability etc. Primitives like AES are pretty strong.