Thinking it over, you don’t really need AES at all, and in any case it doesn’t matter. The initiator doesn’t know the key and doesn’t know the algorithm, so it’s entirely a local matter.
For example, the responder could pick HMAC-SHA256 with a fixed key, and calculate HMAC-SHA256(K,cookie). And it’s not even necessary for the initiator to solve all of the response. We can limit it to 8 Si-s (m=8), each 16 bits (k=16) even though the output of HMAC-SHA256 is 256 bits. m only serves to force the initiator to go through most of the 2^k possibilities. Yoav > On Feb 6, 2015, at 8:30 AM, Valery Smyslov <sva...@gmail.com> wrote: > > I can see two drawbacks with this approach. > > First, to make it aligned with algorithm agility, we need to > negotiate not only PRF, but also the encryption algorithm. > And the selection criteria would become more complex. > > And second - it significantly increases the size of IKE_SA_INIT > response message, as the puzzle must include m hashes. > With SHA256 and m = 8 it is additional 256 bytes. > With SHA512 and m = 16 it is additional 1024 bytes. > That is not good as it increases the chance for IP fragmentation. > > Regards, > Valery. > >> > On Feb 1, 2015, at 8:38 PM, Scott Fluhrer (sfluhrer) > >> > <sfluh...@cisco.com> wrote: >> > >> > If you want to tighten up the time between worse case and average case > >> > time taken by the problem solver, might I suggest this: >> > >> > - When the verifier is asked to generate a problem, it pick a nonce N, > >> > and use it to compute m k-bit values >> S_1, S_2, ..., S_m (for example, S_1 || S_2 || ... || S_m = AES_key(N), >> where the AES key is secret to the verifier), >> and publish k, N, HASH(N, S_1), HASH(N, S_2), ..., HASH(N, S_m) >> > >> > - To solve the problem, the solver needs to produce the values S_1, S_2, > >> > ..., S_m, and send back N, S_1, S_2, ..., S_m >> > >> > - The verifier verifies that the value N was what was originally given > >> > (for example, the nonce might include the solver's >> IP address and a timestamp), and that the values S_1 || S_2 || ... || S_m = >> AES_key(N||0), (or alternatively, >> that those values produces the hashes it sent). >> > >> > The solver can always solve the problem by computing 2**k hashes; with > >> > moderate m, we can make it unlikely >> that it can be done with significantly fewer hashes; I would suggest m=4. >> > >> > Of course, the cost of doing this is a) larger messages, and b) larger > >> > up-front cost generating the problem >> (which, IMHO, isn't too bad -- one AES encryption, and m hash computations; >> however, you are free to disagree). >> > >> >> Hi, Scott. >> >> Thanks for the suggestion. Let me see if I understand it correctly: >> >> Responder has a fixed AES key (let’s call it K). >> >> Let’s assume that N is a COOKIE calculated as in RFC 5996. >> >> The responder Calculates S1||S2||…||Sm = AES(K, COOKIE). COOKIE can be any >> length, >> but for simplicity let’s assume 128-bit so that we don’t have to deal with >> IVs, ICs or any other artifacts >> of modes of operation. Also, let’s set m=8 and all Si as 16-bit. >> So the responder now calculates 8 hashes: for each i Hi = SHA256(COOKIE || >> Si) or better yet, Hi = PRF(Si, COOKIE). >> >> The responder sends to the initiator: >> - The COOKIE >> - Hi for all i. >> - The number k, although that can be deduced from the number of His >> - An identifier for the PRF algorithm chosen. >> >> The initiator needs to find Si values such that Hi = PRF(Si, COOKIE). The >> silly way to do this is to solve run >> through all 2^16 possible Si values once for each Hi (8 times), but a better >> way would be to run once through >> the possible Si-s and find all of them. There is a small chance of making an >> error if two 16-bit values produce >> the same result when using the PRF on the cookie. The initiator repeats the >> request along with the nonce and Si for all i. >> >> The responder now needs to do the following: >> - Verify the COOKIE >> - Encrypt the COOKIE, resulting (hopefully) in the concatenation of the Si >> values. >> >> With the numbers I used in the example, k=16 resulting in 2^16 PRF >> calculations on the client. >> The puzzle can be made harder by increasing k and breaking the encrypted >> COOKIE into larger chunks. >> >> Did I get this correctly? >> >> Thanks >> >> Yoav > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec