3,394 reputation
720
bio website ripple.com
location Oakland, CA
age 45
visits member for 3 years, 4 months
seen Nov 10 at 2:19

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


Jul
4
reviewed Approve length-extension tag wiki excerpt
Jul
4
comment Cryptographic Challenge: How to Say Something Confidentially to Snowden?
You must have some way, in principle, to identify Snowden. If you have such a way, we must know what it is. If you do not, then it is provably impossible -- anything that identifies the Snowden you have in mind could also identify someone else.
Jun
21
comment Is there a hash function which has no collisions?
@improv32: Just use any encryption scheme you like with a key much shorter than the data. (You can easily remove this requirement if needed.) To later prove you had the data earlier, release the key you encrypted it with.
May
12
awarded  Good Answer
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