> -----Original Message----- > From: Paul Wouters [mailto:p...@nohats.ca] > Sent: Wednesday, April 12, 2017 9:48 PM > To: Scott Fluhrer (sfluhrer) > Cc: Tero Kivinen; ipsec@ietf.org > Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing > > On Wed, 12 Apr 2017, Scott Fluhrer (sfluhrer) wrote: > > > It would certainly be simpler to say "take the PPK as an ASCII string, and > hand it off to the PRF as the key", and skip the Base64 conversion; we might > want to suggest a limit on the alphabet of the PPK (as not all implementation > like things with, say, spaces, in them), however that's not a serious > suggestion. > > I would prefer not to add limitations to the byte stream. If someone is using > an actual quantum computer entangled source, that might require additional > post processing to convert it to a reduced ascii set.
I wasn't nearly as clear as I ought to have been; I made some assumptions without stating them. There are, of course, multiple possible PPK sources; one is a preconfigured fixed value in the device; another might be values from a CD-ROM (as others discussed elsethread); still another might be a quantum key distribution device. My discussion was solely about the preconfigured fixed value, and I was just talking about the mapping between 'fixed value' and 'the PPK value you hand to the PRF'; this fixed value will likely be configured as a string (similar to a standard preshared key), my question was the mapping of this string to a PPK value. Now, obviously, there will be other methods of generating PPKs; for those alternative methods, they will likely generate large (256 bit or so) uniform random value; there may be no particular reason to impose any nontrivial mapping there. Obviously, talking about ASCII in that context may make no sense whatsoever. I don't intend to talk about these alternative methods directly in the draft (except to provide a hook to add them later). Does that clarify things? > > For our implementation, we already use a prefix to denote the type of > encoding used for PSKs. And for OTP's in particular, I really do expect to > point > to an actual raw binary file, so needing to convert that to ascii would > actually > be making more work for us to implement. > > It would also make referring to "the offset" a little weird. Is this the > number > of converted-to-ascii bytes or the raw bytes offset? > > Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
