Scott Fluhrer (sfluhrer) writes:
> I've been pondering another question, and I think I'll bring it up
> before finalizing the next version of the draft.
>
> After the WG meeting, we (Tero and myself) met in the hallway and
> had a little chat. One of the things that I took away from it (and
> please correct me if I was wrong) was that you thought that it was
> important that the PPK itself was potentially equidistributed; for
> example, if it was 256 bits long, then all possible 256 bit values
> were representable; after all, we are handling it the PRF as a key.
> On this basis, you suggested that the PPK be encoded in Base64 (and
> converted into binary by each endpoint).
Actually I do not care if all possible 256-bit values can be used, but
care that whatever value I get from somewhere can be used... I.e., if
I have some external distribution method giving me those PPK values, I
want to make sure I can configure both ends to use those values.
> Now, for the specific PRFs standardized in IKE, it's not actually
> that important that all bit patterns be possible. Currently, the
> PRFs defined are HMAC of various hash functions, and XCBC/CMAC
> (which aren't quantum safe). The HMAC PRFs do not actually need to
> make the assumption that the key is equidistributed; it is
> sufficient that there are at least 2**256 possible PPKs (which can
> be ensured by simply allowing the PPK to be long enough).
Yes.
> 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.
Lets say I have external method which generates me a quantum safe PPK
for both ends. Now, I want to make sure I can use that PPK in both
ends, and to make sure it can be used I want to make it sure that I
can configure whatever PPK I get from this external thing to be used
as PPK.
If we use ASCII string, then I need to take my binary blob PPK and
convert it to something that is representable in ascii (for example
hex or base64 encoding).
As my APIs etc will take PPK as binary opaque string with length,
there is no point of restricting myself to just ascii strings there.
It is less error prone to allow me to use the raw binary string than
for example hex conversion of the binary string. For example with hex
strings the result will be different depending whether I use uppercase
or lower case letters. With base64 the result will be different if I
make base64 string without any whitespace, or if I split base64 string
to 72 character long lines.
So for reading the PPK for config file and then converting it to
binary will make this kind of issues disappear, and when the config
file reads base64 string (or hex string) in, and then convert it to
binary object it does not matter whether there is whitespaces etc in
string.
It also make it so that we do not need to care about the character
sets. If we say PPK is string, then we need to know whether it is
ASCII, iso-latin-1, iso-latin-15, utf-8 or whatever.
> On the other hand, it does rather assume that any future PRF will
> also work well with a non-evenly distributed key.
I do not really care whether the PRF works with non-evenly distributed
key, I care that when I configure the same PPK in both ends, I can be
sure the binary object feed to the PRF will be same.
If I configure PPK to be string
Erittäinen salainen merkkijono
to my system, the binary representation of that will be different
depending whether my editor saved it as UTF-8 or Latin-1... If I
configure my sytem to use base64 string of
RXJpdHTkaW5lbiBzYWxhaW5lbiBtZXJra2lqb25vCg==
then both ends will convert it to binary object in same way, and it
does not really matter whether the original string was in UTF-8 or
latin-1 (In this case I think my system used latin-1 for it).
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
