[Swan-dev] Question on get_cookie() code

Andrew Cagney andrew.cagney at gmail.com
Thu Jan 7 16:05:21 UTC 2016


On 7 January 2016 at 10:41, Paul Wouters <paul at nohats.ca> wrote:
> On Thu, 7 Jan 2016, Andrew Cagney wrote:
>
>> Surely, if our FIPS certified random pool is leaking information we've
>> a bigger problem.
>
>
> Yes, hence my "extra paranoid" remark :)
>
>> (any attempt to deplete the entropy pool, should, as a side effect, feed
>> it).
>
>
> That might also give the attack a spoon to stir the cauldron in ways
> that would benefit them. Double edge sword :)

I'm finding this logic circular; is there evidence supporting this?
And again, is the custom code using stuff found on the stack?
I'm sure rule one of cryptography is "never re-invent the wheel"?

At a more technical level, the SPI is fed into the PRF+ vis:

PK11SymKey *ikev2_ike_sa_keymat(const struct hash_desc *hasher,
                PK11SymKey *skeyseed,
                const chunk_t Ni, const chunk_t Nr,
                const chunk_t SPIi, const chunk_t SPIr,
                size_t required_bytes)
{
    PK11SymKey *data = symkey_from_chunk(skeyseed, Ni);
    append_symkey_chunk(hasher, &data, Nr);
    append_symkey_chunk(hasher, &data, SPIi);
    append_symkey_chunk(hasher, &data, SPIr);
    PK11SymKey *prfplus = ikev2_prfplus(hasher, skeyseed, data,
                        required_bytes);
    free_any_symkey(__func__, &data);
    return prfplus;
}

(Ignoring the folly of FIPS compliance).  Isn't the intent is that we,
as best as we can control, feed this with white noise obtained from
within the FIPS boundary?  Using something we made up goes against
that.

Andrew


More information about the Swan-dev mailing list