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.


Sep
24
awarded  Autobiographer
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
awarded  Commentator
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
revised Encrypting or HMACing password digests
added 344 characters in body
Jan
22
answered Encrypting or HMACing password digests
Jan
22
asked Using KDF output for password validation
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
revised Computing IV for CBC from PBKDF2 + HKDF
Additional information and links.
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
17
awarded  Informed
Jan
17
answered Json AES128: Security against known plaintext attack
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.
Jan
15
awarded  Student
Jan
15
revised Computing IV for CBC from PBKDF2 + HKDF
added 29 characters in body