D.W.

7,959 reputation

826

bio	website
	location
	age
visits	member for	1 year, 9 months
	seen	6 hours ago
stats	profile views	137

	7,959 reputation	bio	website		visits	member for	1 year, 9 months
826 badges		location			seen	6 hours ago

summary answers questions tags badges favorites bounties reputation activity

887 Actions

suggestions reviews revisions comments badges posts accepts all

17h	comment	Recommended way of adding a pepper/secret key to password before hashing? @TheDisintegrator, the pepper should be truly random (e.g., generated from /dev/urandom and kept secret thereafter). I don't know about what order your $hash_h mac$ accepts parameters in; I explain where the inputs should go in my answer. As far as how to call bcrypt, that will depend upon your particular language and library's API. If you want to know how to code this up, that's better for StackOverflow. You choose the work factor for bcrypt so that computing bcrypt takes, say, 50ms.
1d	comment	Are there any hand ciphers not obsoleted by computer cryptanalysis? Duplicate of crypto.stackexchange.com/q/1653/351 (see also crypto.stackexchange.com/q/844/351).
1d	answered	Why this k parameter is in unary in adversary PPT algorithm?
2d	comment	When truncating an AES MAC value by “w” , how do I justify that “w” is still negligible? @Maeher, I have a different take. I think it's a perfectly reasonable use of the term. Outside of complexity theory, the standard engineering meaning of the term "negligible" is "so small it can be safely ignored/safely treated as zero". That seems to apply fine here.
2d	comment	Alternatives to HMAC + CBC? It doesn't matter whether you separate out the signature into a separate column or not.
2d	revised	Alternatives to HMAC + CBC? added 485 characters in body
2d	answered	Alternatives to HMAC + CBC?
2d	comment	Is this a sensible cryptographic protocol intending to reduce the impact of compromised security? "The assumption that the compromise wouldn't be permanent is made due to monitoring of all network traffic." - That makes no sense. It is not accurate or prudent to assume that monitoring of network traffic will detect all, or even most, of all compromises (or of instances of exfiltration of data by an attacker). I'm afraid your confidence in ability to detect compromises is sorely misplaced. Just look at some of the APT threats that have managed to penetrate systems and avoid detection for years.
May 17	revised	Hill-cipher, disordered alphabet added 1827 characters in body
May 16	revised	Hill-cipher, disordered alphabet added 1827 characters in body
May 16	answered	Hill-cipher, disordered alphabet
May 16	answered	Is this a sensible cryptographic protocol intending to reduce the impact of compromised security?
May 16	comment	Is this a sensible cryptographic protocol intending to reduce the impact of compromised security? This sounds like a better fit for the IT Security site. It's not really about the cryptography per se, but about threat mitigation. If you click "flag" and ask the moderators to move it, they'll do so.
May 16	revised	Generate fixed length cipher text from arbitrary length plaintext deleted 20 characters in body; edited title
May 16	revised	Generating IV in TLS 1.2 clean up language. no "thanks"
May 16	revised	Hill-cipher, disordered alphabet added 53 characters in body
May 16	comment	Understanding Feldman's VSS with a simple example @mikeazo, that's correct. With those parameters, the Legendre symbol doesn't leak anything about $s$: the Legendre symbol $(g^s\|p)$ will always be $1$, regardless of $s$, so no leakage. Actually, with those parameters, I don't see any way that $g^s$ leaks anything about $s$, so I don't know what the Wikipedia comment is referring to. (Maybe it's what happens if you don't choose $p,q$ that way? Maybe it's the fact that you can verify a guess at $s$ using $g^s$? Or something else entirely? The statement is unsourced, so I can't tell.)
May 16	revised	Generating IV in TLS 1.2 added 130 characters in body
May 16	revised	Generating IV in TLS 1.2 added 304 characters in body
May 16	comment	Generating IV in TLS 1.2 @poncho, OK, thanks. It looks like if you encrypt a (generalized) counter, CBC mode is OK -- but here it's critical that it's a counter that the attacker has no control over. If you allow the attacker any control over the counter-like-thing you're encrypting, then that proof doesn't apply, and I suspect attacks become possible.