Stephen Touset

1,270 reputation

215

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

Cyclist. Rubyist.

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

summary answers questions tags badges favorites bounties reputation activity

247 Actions

suggestions reviews revisions comments badges posts accepts all

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 29	awarded	Quorum
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	revised	Password verification added 1246 characters in body
Apr 25	revised	Password verification added 1246 characters in body
Apr 25	revised	Password verification added 1246 characters in body
Apr 25	answered	Password verification
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.