Reputation
9,539
Next tag badge:
77/100 score
31/20 answers
Badges
3 13 45
Impact
~148k people reached

Jul
20
comment Can Alice send Bob a secure message with only DSA and no key exchange?
I think that as long as the signature generation and verification is performed in the right order that black box key derivation is not possible. I've reused RSA signature generation/verification before but that meant using the public key for generation and the private key for verification - abusing some gaps in the API. Still, I think there is some grey area between using a black box and just the key information that is not completely covered by this answer (although I don't think tricks like above could work for DSA).
Jul
20
revised Reusing keys with AES-CBC
rewrote it in third person, some minor clarifications on the CTR based attack
Jul
20
comment Why don't use random padding in RSA?
@CodesInChaos Well, almost KEM. KEM puts the range at 1..N where N is the modulus. And instead of a hash it uses a KDF. I think the same security features apply though for this almost KEM mechanism.
Jul
19
revised Why should one prefer Salsa20 over ChaCha?
added 38 characters in body
Jul
18
revised 64bit nonce in AES-CTR, why not 128?
added 539 characters in body
Jul
18
answered 64bit nonce in AES-CTR, why not 128?
Jul
17
comment Why does “2xAES-256” provide “99.99%” security strength whereas “1xAES-128” provides “40%”?
"We can high speed convert all file type to 2X AES -256 bits protection. It can defense 99.99% cyber attacks.Many security consultants to ask user to increase the password length and change password frequently,however no one can remember 256 chars long password and key , Only one way is add strong encryption algorithm to protect password and data." ... Well, that deserves a good laugh. I count at least 10 grammar / spelling errors and 3 major cryptographic mistakes. Heck, if you don't know the difference between a bit and a character...
Jul
17
comment How many bits to flip in an RSA public key to do signature forgery?
... but I presume you could detect a forgery if you were suspicious, as setting $d$ to such a low value would make the "private key" easy to factor.
Jul
16
comment EAX cipher mode with nonce equal header
Hmm, interesting. I'll take a look at the Bouncy Castle implementation. Do you have a link to the source code you are referring to?
Jul
16
comment EAX cipher mode with nonce equal header
OK. Note that I don't see any change in the general algorithm even if H is empty. Precalculating H is still advisable. If you don't have too many separate, changing bits you could precalculate it for each possible header.
Jul
16
comment EAX cipher mode with nonce equal header
I would only perfrom micro optimalizations when they are really required. EAX is not the most speedy authenticated mode of encryption, choosing GCM or (even) OCB may make more sense if speed is that important to you.
Jul
16
comment EAX cipher mode with nonce equal header
Heh, posting from work in between assignments; can anybody see the picture? It's blocked :)
Jul
16
revised Is it a good practice to use plain text for derivation of Keys?
added 42 characters in body
Jul
16
comment Is it a good practice to use plain text for derivation of Keys?
Shouldn't it be H = Hash(Random Text + X);? You should clearly specify in your protocol: encryption, decryption, generation & features of data and what you send from one party to the other. Currently your protocol is still ill-defined.
Jul
16
comment Is it a good practice to use plain text for derivation of Keys?
I've updated the answer.
Jul
16
revised Is it a good practice to use plain text for derivation of Keys?
added 476 characters in body
Jul
16
answered EAX cipher mode with nonce equal header
Jul
16
answered Is it a good practice to use plain text for derivation of Keys?
Jul
16
comment Is it a good practice to use plain text for derivation of Keys?
OK, so now you have a Random Text, but it isn't clear how both parties know about the Random Text. Is it send together with the ciphertext?
Jul
12
comment Brute forcing the secret key in Elgamal encryption
p * base still overflows. The remainder op % right after it isn't going to save you. You need to use BigInteger instead.