3,336 reputation
720
bio website ripple.com
location Oakland, CA
age 44
visits member for 3 years
seen Aug 28 at 2:22

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


Aug
28
comment Is there a hash function which has no collisions?
@supercat All you've shown is that the OP is probably making the same mistake you are, believing that it's better to make things impossible than impractical. For practical purposes, which is all that matters, there is no difference. Bijections have huge practical disadvantages and no practical advantages.
Aug
27
comment Is there a hash function which has no collisions?
@supercat That's just not a valid argument. Impossibility is, for practical purposes, indistinguishable from sufficiently impractical. For example, it's trivial to prove that public key cryptosystems cannot possibly make decryption by an attacker impossible (by trial encryption, for example), but such schemes are entirely practical. If you insisted an alarm system make burglary impossible, you'd use no alarm system at all, and that's foolish. You just need to make it impractical.
Feb
4
comment Signing the hash of a key with the same key
Would people really use a signature scheme were signing a piece of public information could compromise your signing key? Wouldn't that be an obvious catastrophic deficiency?
Sep
3
comment Elliptic Curve Cryptography Encryption Results
RSA does not involve any randomness, but it is trivially breakable (if used in the context involved here). Say I send you a message in plaintext, "Should we attack? Respond 'yes' or 'no' encrypting with RSA." This is trivially breakable, you can just trial encrypt both the 'yes' and the 'no'. This is one of the reasons RSA is not used alone. A public key algorithm that operates on short plaintext (which is what we're talking about here) must involve some randomness or it's trivially breakable by trial encryption.
Aug
28
comment Should I delete cryptographic data from memory?
What are you trying to prevent exactly? Presumably an "attacker" who had access to the machine's memory would thereby be entitled to the data the machine had processed. And if your model is that an attacker may have control over the machine while it's processing the data, erasing it later won't help. Are you trying to protect against sensitive data in swap or core dumps?
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.
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
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.