Stephen Touset

1,251 reputation

215

bio	website	touset.org
	location	San Francisco, CA
	age	29
visits	member for	7 months
	seen	1 hour ago
stats	profile views	14

Cyclist. Rubyist.

	1,251 reputation	bio	website	touset.org	visits	member for	7 months
215 badges		location	San Francisco, CA		seen	1 hour ago

summary answers questions tags badges favorites bounties reputation activity

162 Comments

suggestions reviews revisions comments badges posts accepts all

May 16	comment	Generate fixed length cipher text from arbitrary length plaintext Simplistically, such a construct would allow for infinitely efficient compression. Want to distribute a 10TB file? Easy! "Encrypt" it with this scheme and it's now only $n$ bits in size.
May 14	comment	Using an MD5 hash as a password I believe the odds of an "accidental" collision in only $2^{77}$ inputs to MD5 is virtually indistinguishable from zero.
May 10	comment	Is the DES algorithm in OPENSSL random? You're correct that it isn't broken in a cryptanalytic sense. It's just that 56 bits is well within brute force range of even rank amateurs, which for all practical purposes is totally broken. A 56 bit key was brute forced in 1998 on a single desktop computer in a little over two days. Given the advances in hardware, I can't imagine a DES key would last more than a few hours at most against an average modern laptop.
May 10	comment	Is the DES algorithm in OPENSSL random? If you're just asking out of curiosity, great. But you should never, ever, ever use DES for any practical application. It is absolutely 100% broken. Use AES if this is for anything other than toying around.
May 5	comment	Theoretical pi-based stream cipher That is the definition of "normal": all digits have uniform probability in every possible base. And as stated earlier, that doesn't imply that they are distributed randomly, only evenly. To flip your question around, what evidence is there that the digits in $\pi$ are indistinguishable from random? We can't just assume the property of randomness merely because it would be convenient. It must be proven.
May 4	comment	How to derive two keys from one password Why? Using one algorithm is less complicated and has equivalent characteristics.
May 2	comment	Encrypt a single file, chunk-by-chunk, each chunk using different key (AES) Alternatively to CTR, you can simply use GCM mode which has authentication built-in, not requiring a separate HMAC. You can always send distinct blocks to multiple cloud services for storage, but it does require all of the blocks to decrypt any of them.
Apr 29	comment	Custom crypto library in C @user1028028 You asked for advice, and the advice you received has universally indicated that what you're doing is likely a poor idea, and that your "needs" appear to be completely incompatible with sound cryptographic practices. Do with that information what you will.
Apr 29	comment	Custom crypto library in C If you think that adding calls to `sleep` is a good way of preventing timing attacks against a C library, you have absolutely no business implementing your own crypto.
Apr 28	comment	Is this scheme a provably fair random number generation? When the client knows $n$, $o$, and $p$ I don't see how the client can't easily reconstruct $m$ when given $p\equiv m + o \pmod{n}$ and $m < n - 1$
Apr 25	comment	Is this scheme a provably fair random number generation? @DavidSchwartz Do you mean $m$? I'm not sure I follow.
Apr 25	comment	Is this scheme a provably fair random number generation? I think technically the server only needs to send $p$ to the client, since $m$ can be derived (although as stated, the protocol could easily be extended to three or more collaborating parties)
Apr 25	comment	Password verification @bic "Is the process in actuality broken?" is really the wrong question to be asking, and I hope to disabuse you of that line of thinking in the first place. The answer is practically always going to be "yes" in situations like this. That still applies even if you, I, or even an experienced cryptographer don't immediately know the exploitable flaw. Additionally, there are all manner of possible vulnerabilities that can and will crop up during the implementation of the protocol, even if the protocol itself is secure.
Apr 25	comment	Theoretical pi-based stream cipher @DavidCary The Champernowne constant is normal, but its $n$th digit is clearly not a uniform random variable.
Apr 24	comment	Tamper-proofing log files I do. I was referencing your comment about "if I was doing encrypt-then-MAC...". It sounded like that was your plan.
Apr 24	comment	Tamper-proofing log files Then don't implement encrypt-then-MAC yourself. :)
Apr 24	comment	Tamper-proofing log files As with any crypto, I would strongly recommend against implementing your own AEAD scheme. Windows implementations exist — investigate them before rolling your own.
Apr 24	comment	Tamper-proofing log files The last concern is trivially solved. If there are no logs for a date, you can still write an empty file.
Apr 24	comment	Tamper-proofing log files You could always run nix on a remote logging server. This also has the advantage of requiring an attacker to break into two* boxes to undetectably compromise one of your services.
Apr 24	comment	Tamper-proofing log files I mentioned attributes, not permissions. Limiting permissions on sensitive files is simply good hygeine and should go without saying.