3,326 reputation
620
bio website ripple.com
location Oakland, CA
age 44
visits member for 2 years, 11 months
seen 1 hour ago

I am Chief Cryptographer at Ripple Labs and one of the architects of the Ripple payment system.


Apr
27
comment How can a key pair be derived from an arbitrary hash?
Yes, it basically is.
Apr
27
comment Is it possible to determine a PGP public key from encrypted data?
The decrypted content is of no help accomplishing this task. But he can trivially do it because the PGP file contains the ID of the key needed to decrypt it.
Apr
27
answered How can a key pair be derived from an arbitrary hash?
Apr
14
comment How to use salt if I am sending hashed password?
Step 3 is essential, do not skip it.
Apr
3
comment Is there a practical security difference between XXX-bit encryption?
This is not quite true. Consider, for example, if the process of generating the secret key from the password is extraordinarily computation intensive. If it's, say, a billion times harder to test if a guess at the password is correct than it is to check if a guessed secret key is correct, that can effectively make the password 30 bits longer relative to the secret key.
Apr
1
comment Decrypt digital signature using RSA public key with openssl
How many bits is the RSA key you are using? "data greater than mod len" usually indicates either a "toy" key that doesn't have enough bits or an attempt to operate on the actual data where you should be operating on a hash.
Mar
26
comment which asymmetric cipher provide highest performance?
Are you talking about bulk encryption/decryption of large amounts of data? Or are you talking about large *numbers) of encryption/decryption operations of small amounts of data? (If the former, I think you don't understand how asymmetric ciphers are used.)
Mar
22
comment Even passwords are vulnerable to hash collision attacks?
For 6 or 7 character passwords, there's no point in worrying about hash collisions. Just guessing the password would be much easier.
Mar
19
comment Key Exchange and anonymity issue
@PaŭloEbermann: Bob sets up a well-known rendezvous point the same way Alice sets up the return path, building it up hop-by-hop. The first hop has no idea it's talking to Bob and no idea it's the first hop. The last hop has no idea who the first hop is. (The last hop, of course, knows the path goes to Bob and that it's the last hop, that's how Alice finds a path to Bob.)
Mar
19
comment Key Exchange and anonymity issue
@Alexandera: How is that different? That's saying that Bob encrypts the file such that Alice can decode it. The encryption is still end-to-end -- bob encrypted it, only Alice decrypts it.
Mar
19
comment Key Exchange and anonymity issue
@Alexandera: Of course we do. The first thing Bob does with any message he sends to Alice is encrypt it with her public key so only she can decrypt it. Everything else comes after that first step. (And, in fact, each step does that. When B sends a message back to A, it first encrypts it with A's public key because A and B may not be directly connected.)
Mar
19
comment Key Exchange and anonymity issue
@Alexandera: In other words, Alice sets up a secure connection to A. Then using that secure connection, sets up a secure connection from A to B, where A uses the secure connection to get its end to her. Then using that, she builds a secure connection from B to C, such that B hooks up its end of that connection to the pipe between A and B. And so on, eventually hooking up to Bob. B knows the connection comes from C and goes to A, but that's it. Bob knows the connection goes to C, and that's it. And so on.
Mar
19
comment Key Exchange and anonymity issue
@Alexandera: Alice includes her public key (which can be one she just created only for this communication if that's what she wants) in the communication to Bob. This ensures only Alice can decrypt the content (unless Bob chooses to let others see it, of course). As for securing the path, Alice constructs the return path hop-by-hop, instructing each hop how to use the rest of the path to get packets back to her. Again, all those nodes would have to conspire to compromise her location. Each node does not know what Alice has set up behind it.
Mar
19
comment Key Exchange and anonymity issue
@Alexandera: No. Alice encrypted the packet with Bob's key in the first place, so only Bob can get the decrypted contents. The last node decrypts the packet with its key and finds inside another encrypted packet which it forwards to Bob. It has no idea what's inside that encrypted packet since it doesn't have Bob's key. So far as the node talking to Bob knows, he might be the final destination or he might unwrap another encrypted packet he sends to someone else. And, of course, that node has absolutely no idea who the originator is.
Mar
19
comment Key Exchange and anonymity issue
@Alexandera: Why wouldn't they be able to remain anonymous? All the communications are re-encrypted on each hop and unless lots of nodes are conspiring, nobody knows the whole path. (Even the node Alice is communicating directly with doesn't know it's communicating directly with Alice. For all it knows, Alice got the data from another node. Ditto for Bob's node, which has no idea it's the last node in the path.)
Mar
19
answered Key Exchange and anonymity issue
Mar
18
comment Where to store the private key and the public key in a communication protocol
@TalehIbrahimli: To give you an analogy, think of a guy building a suspension bridge to carry trucks who says, "The design of other suspension bridges is too complicated for me to understand and customize, I'll just design a bridge from scratch." Would you drive over that bridge?!
Mar
18
comment Where to store the private key and the public key in a communication protocol
@TalehIbrahimli: Honestly, your reasoning is so unbelievably disconnected from reality that you have no business choosing or implementing a security scheme. I'm not trying to be mean, I'm trying to protect you (and anyone who relies on your software) for disaster. If you find using SSL properly too hard, you have absolutely no business attempting the much, much harder task of implementing the encryption scheme itself, much less designing one.
Mar
11
comment Where to store the private key and the public key in a communication protocol
@CodesInChaos: Sure, you can take SSL and improve it by removing legacy issues, but then it won't be better because it's "unknown to cryptanalyst". It will be better because it is based on structures that are very well known and well understood. And I'd still worry about the risk that you'll create new, and much more serious, vulnerabilities.
Mar
11
comment Where to store the private key and the public key in a communication protocol
"I think custom protocol is unknown to cryptanalyst. And for this reason , it will be more secured." If the protocol is unknown to cryptanalysts, then there is no way to know how secure it is. By contrast, SSL was carefully constructed by industry experts to be as secure as humanly possible and has been extensively analyzed and tested. The odds that you implement something more secure than SSL are essentially zero. Most likely, it would turn out to be horribly broken (as early versions of SSL turned out to be).