10,257 reputation
12452
bio website github.com/CodesInChaos
location Frankfurt, Germany
age
visits member for 3 years, 5 months
seen 18 hours ago

Jan
26
comment Factorization or discrete logarithm is difficult for an attacker?
I know no secure signature scheme within your constraints. But if both signer and verifier share a secret, they can use a MAC instead of a signature. MACs fit your constraints, but the verifier can forge them, so it doesn't work well with more than two parties.
Jan
25
comment A fast non-cryptographic hash function that is “strong enough”?
AES with a fixed key could be used as one-way function: $H^{i+1}=AES(H^i) \oplus H^i$. But it's not a recommended mode.
Jan
24
comment Question about SHA-2 (and potentially similar hashing algorithms)
The idea of a hash is that anybody can compute the same hash without having to know a secret. When you have a secret, you can use a MAC which is stronger than an unkeyed hash. The random prefix keys used in for example HMAC are very similar to random IVs.
Jan
24
comment How to protect against ephemeral key reuse in some signature schemes?
There is one risk worth guarding against though: A failing PRNG. That's why I recommend deterministic nonce generation like EdDSA or RFC6979 - Deterministic Usage of the Digital Signature Algorithm.
Jan
24
comment How to protect against ephemeral key reuse in some signature schemes?
The risk of your counter measure having a bug that causes trouble is bigger than the change of repeated nonces with a perfect PRNG. Even the risk of random hardware errors is much bigger. $2^{-200}$ is really really small.
Jan
23
comment Using KDF output for password validation
How are you deriving the key?
Jan
23
comment Using KDF output for password validation
I'd call HKDF-Expand twice with different strings, once for the IV and once for the validator. Or implicitly use a MAC as validation. One could also consider using HKDF-Extract on the password and feeding its output to PBKDF2.
Jan
23
comment RSA with composite numbers
RSA uses a composite modulus. Usually it is the product of two primes (called a semiprime), but you could use more if you want.
Jan
22
comment Can curve25519 keys be used with ed25519 keys?
The problem is that you don't get the y part of the coordinate when using a montgomery ladder to compute the public key.
Jan
22
comment Encrypting or HMACing password digests
This question is about encrypting/MACing a salted password hash.
Jan
22
comment How can i predict the next number of a long sequence of seemingly random numbers?
@figlesquidge Typical stream ciphers don't come with a meaningful proof of security. Security of symmetric primitives generally comes down to "many smart cryptographers tried to break it, but none succeeded".
Jan
22
comment inverse of scalar multiplier in ECC
My mistake. You're right. A simple modular inverse should do the trick. Computing a modular inverse costs about 10% of a scalar multiplication $aQ$. So computing $a^{-1}Q$ is dominated by the cost of multiplying $Q$ with $a$.
Jan
21
comment TLS: Is Integrity assured when using NULL cipher
1) How much data do you send per connection? For short connections the handshake cost will dominate. Switching to ECDHE-ECDSA should reduce the cost of the initial handshake. 2) Do both server and client support some form of session resumption? Session resumption allows you to omit the handshake when establishing multiple connections. 3) What CPU are you using? On CPUs with AES-NI, AES is very fast, consider using TLS 1.2 with AES-GCM on those CPUs.
Jan
21
comment How to ensure that a “received value” is not altered?
Sounds like a standard unsolvable DRM problem. Only thing you can do is throwing obfuscation at it and praying.
Jan
20
comment In what way is XXTEA really vulnerable?
I'd agree with you if this question were about actual security. But since this question is about DRM (a licensing scheme) it almost certainly relies on security-through-obscurity. Compared to the attacker simply extracting the key or patching the software, the risk arising from a weak blockcipher like XXTEA is probably negligible.
Jan
20
comment Are there groups where the computational Diffie Hellman problem is easy but the discrete log problem is hard?
AFAIK there are no know groups where this is the case, but we know no proof that shows they don't exist either.
Jan
20
comment In what way is XXTEA really vulnerable?
"there are other, simpler ways to defeat the licensing mechanism than launching a cryptographic attack on the license file data." I completely agree with that statement. But it's not clear to me that you actually want encryption in the first place. A MAC or a digital signature might fit your needs better.
Jan
20
comment Which is better ECDHE with TLS 1.0
@fgrieu 1) Most browsers mitigate BEAST, even on TLS 1.0 2) BEAST (like all other attacks based on TLS using MtE instead of EtM) is inherently an active attack. RC4 has some weaknesses even against passive attacks. 3) BEAST seems to be tricky to exploit in practice. The original attack needed browser features/bugs no longer present.
Jan
17
comment Which is better ECDHE with TLS 1.0
@GiovanniNervi Some clients are vulnerable to BEAST. The rest have implemented workarounds even on TLS 1.0. I consider BEAST to be a smaller issue than RC4 sucking.
Jan
17
comment Which is better ECDHE with TLS 1.0
At minimum you can eliminate 3DES, it's strictly worse than AES. And NULL is obviously not useful either when you're interested in confidentiality.