lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 23 Sep 2021 10:49:53 +0300
From:   Leonard Crestez <>
To:     Jakub Kicinski <>
Cc:     Dmitry Safonov <>,
        David Ahern <>,
        Shuah Khan <>,
        Eric Dumazet <>,
        "David S. Miller" <>,
        Herbert Xu <>,
        Kuniyuki Iwashima <>,
        Hideaki YOSHIFUJI <>,
        Yuchung Cheng <>,
        Francesco Ruggeri <>,
        Mat Martineau <>,
        Christoph Paasch <>,
        Ivan Delalande <>,
        Priyaranjan Jha <>,
        Menglong Dong <>,,,,
Subject: Re: [PATCH 00/19] tcp: Initial support for RFC5925 auth option

On 9/22/21 2:13 AM, Jakub Kicinski wrote:
> On Tue, 21 Sep 2021 19:14:43 +0300 Leonard Crestez wrote:
>> This is similar to TCP MD5 in functionality but it's sufficiently
>> different that wire formats are incompatible. Compared to TCP-MD5 more
>> algorithms are supported and multiple keys can be used on the same
>> connection but there is still no negotiation mechanism.
> Hopefully there will be some feedback / discussion, but even if
> everyone acks this you'll need to fix all the transient build
> failures, and kdoc warnings added - and repost.
> git rebase --exec='make' and scripts/kernel-doc are your allies.


I already went through several round of testing with git rebase 
--exec='$test' but it seems I introduced a few new failures after 
several rounds of squashing fixes. I'll need to check kernel-doc 
comments for source files not referenced in documenation.

Many of the patch splits were artificially created in order to ease 
review, for example "signing packets" doesn't do anything without also 
"hooking in the tcp stack". Some static functions will trigger warnings 
because they're unused until the next patch, not clear what the 
preferred solution would be here. I could remove the "static" marker 
until the next patch or reverse the order and have the initial "tcp 
integration" patches call crypto code that just returns an error and 
fills-in a signature of zeros.

A large amount of the code is just selftests and much of it is not 
completely specific to TCP-AO. Maybe I could try to repost the parts 
that verify handling of timewait corners and resets in a variant that 
only handles "md5" and "unsigned"?

I already tried posting my scapy implementation of TCP-AO and MD5 to 
scapy upstream because it is not specific to linux .


Powered by blists - more mailing lists