New answers tagged

8

You need to split this up into two separate problems: you may have a low entropy password (as you indicate you want to have "tunable difficulty"); you need the keys of a specific user not to reveal any information about the password or the other keys. Lets solve this in two steps: First you need a salt and a work factor or iteration count. You can do ...


3

I'll quickly summarize your situation as a TL;DR: You provide a service, using your server, which requires users to get a key, which is identical across devices, without wanting the user to fetch a salt from the server for each log-in and you're only given a low entropy secret to derive a (somewhat) secure key. Safely deriving keys from passwords requires a ...


3

Like Yehuda Lindell already wrote, MAC does not imply PRF, which is pretty much what you would want from a KDF. Additionally, some of your assumptions are not correct: A key and data as input and an output that has the same length as the input key; This is frequently not the case with MACs. For example, when you use any MAC based on AES-256 (...


12

No. A MAC guarantees unforgeability but not pseudorandomness. It is true that all MACs that I can think of right now are essential pseudorandom functions, but this does not mean that the MAC definition implies this. Indeed, it clearly does not. So, conceptually, you need a pseudorandom function. You can assume that HMAC is a pseudorandom function. It is ...


7

Read Marsh Ray's analysis. PRF in TLS is designed to be the most conservative aspect of TLS (the last part of TLS to break). Mr. Marsh calls it "the slowest, most conservatively designed stream cipher in common use". TLS PRF seems to be NIST sp800_108 in "Double Pipeline Mode". What Tim McLean contemplates above as a potential alternative is sp800_108 in "...


2

Are there any memory-hard PBKDF constructions that can be implemented using only common standard crypto primitives, like (generic) hash functions and/or block ciphers? Of course there is one, and it even got a "special recognition" at PHC: Catena. I won't go into the details of Catena here (the paper does it much better on its 50+ pages), but it comes ...


2

Yes, PGP allows different-sized subkeys and subkeys are not derived of the main key, so it is possible to have the earlier key be a subkey of the new one. How to do it is off topic here, but this should get you started if you use GnuPG.


1

For full explanation, see Is there a standard for OpenSSL-interoperable AES encryption? . Short answer: what openssl enc (without -K for raw) uses is not PBKDF2; it is almost PBKDF1, with iteration count 1. This imposes almost no cost on attacker trials, so unless your passwords are strong enough to be keys by themselves you should avoid it if you can. In ...


1

OpenSSL uses EVP_BytesToKey, an algorithm proprietary to OpenSSL, with a salt and an iteration count set to 1. The algorithm isn't that insecure; the iteration count of 1 of course is. There are implementations for other languages/runtimes if you look for it. This page (on nabble.com) explains a bit about accessing PBKDF2 from the command line. It also ...


2

It will be uniformly random for such a simple statistical test. The problem is that you are treating the probability of bits having a particular state as independent of each other. You would need to look at the conditional probability distributions of certain bits being set given other bits. The entire joint distribution of output and input bits for a ...


3

What you actually want is called a key-based key derivation function (KBKDF). The most prominent KBKDF (and really the standard solution here) is HKDF. This is a function that takes a secret key (e.g. a KEK or a root key or something) and outputs (a set of) derived keys enjoying some nice properties. You can customize the keys to get different keys for ...



Top 50 recent answers are included