Reputation
12,178
Next tag badge:
89/100 score
20/20 answers
Badges
1 30 60
Newest
 Yearling
Impact
~205k people reached

Feb
18
comment Block Cipher vs Stream Cipher in Web Application
My experience is that there is a movement away from traditional block cipher modes like CBC towards stream cipher modes. For example AES-GCM is based on the AES-CTR, a stream cipher mode. Google will probably add TLS suites based on the stream cipher ChaCha soon, and I believe some SSH implementations already did add similar suites.
Feb
18
comment Block Cipher vs Stream Cipher in Web Application
1) RC4 is unfortunately common. 2) There is no reason to believe that stream ciphers are weaker in principle than block ciphers. For example Salsa20 or Keccak in duplex mode are believed to be secure. 3) You can build stream ciphers from block ciphers, e.g. AES in CTR mode is a stream cipher. This proves that if you know of to build a secure block cipher, then you can also build a secure stream cipher.
Feb
18
comment RSA vs El Gamal digital signature. Which is more secure?
I don't see how that's a duplicate. This question is about RSA and ElGamal signatures, the other question about RSA and ElGamal encryption.
Feb
18
comment Proof of work for standard computers
@D.W. 1) Scrypt with sufficient memory (say 1GB) use isn't cheap to verify. Scrypt is pretty much the baseline against which to compare a better scheme. 2) The only time lock puzzles I know are sequential, but don't need much memory. So you can solve many instances in parallel with many cheap cores.
Feb
17
comment IV/Nonce in CTR&GCM mode of operation
In scenarios where you want random IVs, you probably can afford a hashing operation per message, so you could derive a per-message key from a master key and a longer per-message random value.
Feb
17
comment GCM encryption for 256-bit and 512-bit block ciphers
@owlstead Security and block size are only loosely coupled. The main advantage of larger block sizes is that you get larger IVs, so you can safely use a random IV. I'd guess the main reason for using larger block sizes is that your cipher (say Threefish) happens to have larger blocks.
Feb
17
comment IV/Nonce in CTR&GCM mode of operation
GCM IVs are typically 96 bits, which is rather short for random generation.
Feb
17
comment Can a properly implemented ed25519 private key with public underlying data be cracked?
There are signature algorithms with either a strictly limited number of signatures (typical hash signatures) or which get weaker as more signatures are generated.
Feb
17
comment Block Ciphers and (Non-)Generic Attacks
A generic attack works against all block-ciphers with a given key and block size.
Feb
17
comment GCM encryption for 256-bit and 512-bit block ciphers
Why would you have to choose a larger field? AFAIK GCM only uses the underlying cipher as stream cipher, so the block size shouldn't matter at all (if it is at least the field size, for smaller blocks a bit of special handling might be required)
Feb
14
awarded  Enlightened
Feb
14
awarded  Nice Answer
Feb
12
comment Prime factorization of RSA modulus
$m^{e_1d_1-e_2d_2}=1$ mod $N$ follows from $m^0=1$ and $e_1d_1-e_2d_2=0 \mod \phi(N)$
Feb
12
comment Prime factorization of RSA modulus
Typically $e$ is the public key, not the private key.
Feb
12
revised Why do we use 1024 / 160 bit primes in DSA?
added 10 characters in body; edited tags; edited title
Feb
12
revised Why do we use 1024 / 160 bit primes in DSA?
added 2 characters in body
Feb
12
revised Safe and computationally efficient way to verify a curve25519 identity?
edited tags
Feb
12
comment Safe and computationally efficient way to verify a curve25519 identity?
You can't achieve meaningful security without at least applying a MAC to the data you send. Unless you have severe performance limitiations, I'd go with authenticated encryption, like the CurveCP protocol does. I recommend to implement CurveCP over TCP (you don't need the tricky flow control part, only the simple crypto part). It's not perfect, but still much better than what you're thinking of.
Feb
12
comment Safe and computationally efficient way to verify a curve25519 identity?
You should use an existing higher level protocol, like CurveCP. You're not ready yet to design your own protocol.
Feb
12
comment Safe and computationally efficient way to verify a curve25519 identity?
1) Authentication always needs to be bound to something. A message or an integrity protected channel. You cannot just authenticate. 2) Your scheme suffers from trivial forwarding attacks where an attacker impersonates the server to learn shared keys. 3) You need to apply some form of MAC, not the key itself. Else an attacker impersonating a server can learn arbitrary shared keys.