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

Mar
5
comment How fast can a wrong decryption key be detected using ECC?
@Sibbo bitmessage uses ECIES. This means that ECC is used to produce a shared key, which is then used for encryption (AES-CBC) and MAC (HMAC-SHA-256). A wrong key will lead to a MAC verification failure.
Mar
5
comment Fast modular reduction
@fgrieu I bet they want to do whatever Secp256k1 requires.
Mar
5
comment Long-term data protection, storage of old encrypted traffic and quantum cryptocalipse
@Thomas A big quantum speedup for travelling salesman would be a far bigger revelation than even breaking 4096 bit RSA, since QCs are not believed to solve NP complete problems quickly. D-Wave can solve one specific optimization problem which is closely related to their physical structure. They don't entangle many qubits at the same time, can't run shor, it's dubious that they even offer a quantum speedup for their one favourite optimization problem. In short, D-Wave is useless and not representative of real quantum computers.
Mar
5
comment Long-term data protection, storage of old encrypted traffic and quantum cryptocalipse
@Thomas Just because there are no large quantum computers yet,(don't remember the precise current state of the art, but it's around 5 qubits factoring huge semi-primes like 15) doesn't mean that there won't be such QCs twenty years from now. If you want long term confidentiality QCs resistance should be a consideration.
Mar
5
comment Prime factors of non-random keys
Another related article There’s no need to panic over factorable keys–just mind your Ps and Qs. @fgrieu That paper is pretty high on my list of "dumbest paper titles".
Mar
3
comment Three-way hash collision
You get a $2^l$ way collision with cost $l \cdot 2^{64}$. So you get a 16-way collision with cost $2^{66} = 4 \cdot 2^{64}$ not just an eight-way collision.
Mar
3
comment Machine Learning with Encryption
Related questions: Any practical uses of machine learning for cryptography? and Cryptography based upon neural networks
Mar
3
comment Machine Learning with Encryption
You might be able to throw machine learning at side-channel or meta data. But that's a bit beyond crypto per-se.
Mar
3
comment Machine Learning with Encryption
The crypto techniques somewhat related to machine learning that I know of are 1) using SAT solvers as part of cryptoanalysis 2) Learning with error problems in lattice based crypto
Mar
3
comment Check the validity of a rsa key pair with only the public key?
Blind RSA signatures might have some issues if the modulus has a small factors since padded signatures/blinding factors might share factors with the modulus.
Mar
3
comment Derive both MAC and AES keys from same PBKDF2?
@fgrieu I mainly base it on performance, i.e. on the issue describes in that answer. I also think that being able to specify an arbitrary info string is nice.
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
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
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
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.