lkml.org 
[lkml]   [2022]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH RFC v1 2/3] ipv6: move from sha1 to blake2s in address calculation
    On 1/13/22, Ard Biesheuvel <ardb@kernel.org> wrote:
    >
    > The question is not whether but when we can/will change this.
    >
    > SHA-1 is broken and should be removed at *some* point, so unless the
    > feature itself is going to be obsolete, its implementation will need
    > to switch to a PRF that fulfils the requirements in RFC7217 once SHA-1
    > ceases to do so.
    >
    > And I should also point out that the current implementation does not
    > even use SHA-1 correctly, as it omits the finalization step. This may
    > or may not matter in practice, but it deviates from crypto best
    > practices, as well as from RFC7217
    >
    > I already pointed out to Jason (in private) that the PRF does not need
    > to be based on a cryptographic hash, so as far as I can tell, siphash
    > would be a suitable candidate here as well, and I already switched the
    > TCP fastopen code to that in the past. But SHA-1 definitely has to go.
    >

    Correction: this should be a cryptographically secure. That's part of
    the point of moving away from SHA-1 of course. But fortunately,
    siphash *is*
    considered to be cryptographically secure. Whether you want blake2s's
    keyed mode or siphash doesn't really matter to me. I thought the
    former's API mapped a bit neater here.

    \
     
     \ /
      Last update: 2022-01-13 13:23    [W:3.165 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site