3,354 reputation
720
bio website ripple.com
location Oakland, CA
age 44
visits member for 3 years, 1 month
seen Sep 9 at 16:58

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


Jan
17
revised What does a “cycle” mean in cryptography benchmarks?
deleted 31 characters in body
Jan
15
answered What does a “cycle” mean in cryptography benchmarks?
Jan
15
answered A proof-of-work random number generation system for Pokémon
Jan
15
answered Is the One Time Pad (OTP) considered a cryptographic hash function?
Jan
15
comment Is the One Time Pad (OTP) considered a cryptographic hash function?
@Woot4Moo: Without a compression function, OTP is not a hash. With any non-trivial compression function, OTP is not just OTP anymore. With a trivial compression function, OTP is not cryptographically secure. But ignoring that, OTP is reversible, so useless as a hash function.
Jan
9
comment Why is ciphertext from low entropy plaintext not compressible?
It would be a crappy encryption scheme that didn't hide the fact that the plauntext was so compressible. The whole point of encryption is to deny someone who has the ciphertext any information about the plaintext. (Other than that it can have no more entropy than the ciphertext has -- that's unavoidable.)
Dec
18
comment Good enough deterministic PRNG based on hashes
@IlmariKaronen: Why shows why you should never roll your own crypto algorithm.
Nov
10
comment Can there be two hash functions without common collisions?
The answer to "what do I do about it" is simple: Since you get to choose the hash algorithms, just choose algorithms such that the probability of such a collision is low enough that you can ignore it. (Say, less than one hundredth the probability that you'll fail by your most likely failure mechanism with comparable failure consequences.)
Nov
6
revised finding collision for truncated SHA1 hash output
added 252 characters in body
Nov
6
answered finding collision for truncated SHA1 hash output
Oct
18
comment Prevent double-spending with decentralized digital currencies without all transactions being public?
@IainStewart: There's actually a trivial solution to that. Instead of the transaction including the encrypted private key needed to claim the funds, it can include the encrypted "private key offset" that the recipient can apply to his private key to produce the private key he uses to claim the funds. Since the sender doesn't know the recipient's private key, he cannot claim the transaction. So you can get it that way if you want it. (This works the same way deterministic wallets work where you can craft a new public key that only someone else knows the corresponding private key to.)
Oct
1
comment What algorithm could/should be used to encrypt files for storage on untrusted servers?
Unless you at least know the information necessary to make a decision like that, you should hire someone to help you make that decision. From the way this question is asked, we can't even tell the most basic things about the type of encryption you need.
Sep
1
comment verify contents, but not order
The problem is underspecified, but as asked, I'd answer this: Use an encryption scheme that maps each card to a number from 1 to 52. Ensure that all numbers from 1 to 52 are present, each once. Since you can't decrypt any of them, you have no idea what their order is. But since each of the 52 ciphertexts appears once, each of the 52 plaintexts must too.
Aug
30
comment Proof of work for standard computers
@CodesInChaos: If a computer with a billion cores solved it a billion times faster, that would give no advantage for the specialized hardware. You could just as well use a billion regular cores. (For algorithms like SHA256, a specialized computer with 200 cores can be millions of times faster than a general purpose computer with 4 cores.)
Aug
30
comment Proof of work for standard computers
@CodesInChaos: It just needs to be about equally hard on both. Algorithms would be memory-limited, and specialized computers don't have a significant memory advantage over general-purpose computers like they do with calculations not involving tests or branches (like SHA256).
Aug
30
comment Proof of work for standard computers
@CodesInChaos: The worse it works, the better. The idea is to make it hard.
Aug
29
comment Storage of Private Keys
@JordanArseno: CodeInChaos is saying that you've made the problem more difficult than it has to be by coupling a spend from the user with a transaction from their deposit account. If you uncouple those two operations, you have many more options. (However, you will lose the ability to prove you have a 100% reserve.)
Aug
27
comment Storage of Private Keys
Encrypt the private key with the user's password so that you can decrypt it with the password. The encryption with the master public key is only used if the user's password is lost.
Aug
27
comment Storage of Private Keys
No. For a spending transaction, you use the user's password to decrypt the private key. The master private key is only used if the password is lost. (This is the recovery mechanism, not the normal mechanism.)
Aug
27
answered Storage of Private Keys