335 reputation
17
bio website robnapier.net
location Raleigh, NC
age 42
visits member for 3 years
seen Oct 9 at 20:41

Rob is a builder of treehouses, hiker, proud father, and in his spare 50-60 hours a week, a Mac and iPhone developer. He's coauthor of iOS 6 Programming Pushing the Limits. Cocoaphony is where he pontificates on various issues fascinating to Cocoa developers, and occasionally other topics of technical interest. You can find more information about him on LinkedIn. Or mail him at robnapier on gmail. Now and then he tweets at @cocoaphony.


Jan
24
comment Using KDF output for password validation
Much as I love the crypto world, it seems to me that crypto guys spend a lot of time writing papers and low-level primitives that you have to assemble yourself perfectly, and not much time making it accessible to the average programmer. If you make a small mistake, it's all broken, but there's no way to know you screwed up. I wanted to provide something for the everyday programmer who is looking for a one-line encryption call that will "do the right thing," and that they could easily send to their server written in some other language.
Jan
24
comment Using KDF output for password validation
That's been my concern all along. But I can't find a really standard and easy-to-use data format available for password-based AES. That's what led me to create RNCryptor (and to constantly look for review). If you have an example of something that's standardized, and can be easily implemented in many languages and platforms using commonly available primitives, I'm eager to move to it. The closest I ever found to a "standard" was CMS, and that is a royal pain to implement correctly.
Jan
23
comment Using KDF output for password validation
Thanks. BTW, I have considered scrypt and bcrypt. I've chosen PBKDF2 because of its ubiquitous availability. I am strongly trying to avoid implementers writing any more crypto primitives than absolutely required. rncryptor.github.io/blog/2014/01/21/why-not-scrypt
Jan
23
comment Using KDF output for password validation
Full spec is here: github.com/RNCryptor/RNCryptor-Spec/blob/master/…. If you pass I key, I use HKDF-Extract. If you use a password, I use PBKDF2.
Jan
23
comment Using KDF output for password validation
I originally called the HKDF twice, but I did have some concern at truncating a 512-bit hash down to 128 bits. I'm using SHA512 because it's called for by draft-mcgrew-aead-aes-cbc-hmac-sha2 for AES256, and I'd like to keep the number of primitives required to a minimum.
Jan
23
comment Using KDF output for password validation
"You are trying to generate your own KBKDF." I don't quite understand. The KDF I'm using here is exactly HKDF (RFC 5869), isn't it?
Jan
23
comment Encrypting or HMACing password digests
The client should definitely perform the bcrypt before sending the result to the server. That shouldn't even be controversial. The client should never send raw password if it can be avoided. I'm discussing a separate hash by the server prior to putting into the database. I believe that provides stronger protection than symmetric encryption. HMAC provides only marginally better protection than SHA for that final hash IMO. I am aware of the layers; SHA/HMAC is providing a more effective layer than symmetric encryption.
Jan
22
comment Can I use my random IV (for AES) as a salt for PBKDF2?
Totally agreed; I should have said "predictable by the attacker." I have a more detailed version of this question: crypto.stackexchange.com/questions/12943/…
Jan
22
comment Can I use my random IV (for AES) as a salt for PBKDF2?
TLS 1.0 computed the IV in a way that was knowable by the attacker, and this led to a "CBCATT" (openssl.org/~bodo/tls-cbc.txt). TLS 1.1 switched to an explicit IV. I don't believe that this undermines the answer, though, but would like to confirm that.
Jan
16
comment Json AES128: Security against known plaintext attack
When you say "I am transmitting json messages securely," what exactly do you mean? AES-128 does not sufficiently describe your message format. AES-128 is only capable of transforming exactly 16 bytes, so I assume you're also using a block cipher mode like CBC on top of it. Which mode are you using? Are you including an HMAC or using an authenticated mode? Are you using a password (if so, what is your KDF?) These answers have a lot of impact on the security of the system and the answer to this specific question.
Oct
4
comment How does one scale encryption strength upwards from 256-bit?
+1 Excellent discussion. One point, however, about the overkill of long keys. This assumes that a believed strong algorithm is in fact strong. If a break is found against the algorithm, then extra key bits can certainly provide a valuable safety margin. You hint at this in your answer at security.SE when you discuss QC (which could be considered a kind of "break"), but I wanted to bring it forward here as well.