Reputation
3,529
Top tag
Next privilege 4,000 Rep.
Access 'trusted user' tools
Badges
8 22
Newest
 Yearling
Impact
~65k people reached

Jan
29
comment Is there a length-preserving encryption scheme?
To 100% clarify, you are looking for an encryption algorithm that maps every possible binary input with an integral number of bytes to a encrypted output of the same length. Is that correct? And you understand the inherent security problems with such an algorithm? (No defense against corruption, replay attacks, and so on.)
Jan
19
comment Is it safe to use RSA as a proof-of-work system?
In the vast majority of realistic applications, any proof of work system can be parallelized simply by requesting many challenges from the server.
Jan
19
comment Is it safe to use RSA as a proof-of-work system?
Another option is to have the server generate two primes and give the client the product of the two primes. The client must factor the product and return the smaller prime.
Jan
19
comment A proof-of-work random number generation system for Pokémon
I think that's a distinction without an actual difference. If it doesn't happen, what difference does it make if it didn't happen because it was impossible or because it was unlikely? If I die without having won the lottery, does it matter to me that it wasn't impossible?
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.