On Thu, Dec 22, 2016 at 03:49:39AM +0100, Jason A. Donenfeld wrote:
>
> Funny -- while you guys were sending this back & forth, I was writing
> my reply to Andy which essentially arrives at the same conclusion.
> Given that we're all arriving to the same thing, and that Ted shot in
> this directio
Hi Ted,
On Thu, Dec 22, 2016 at 6:41 AM, Theodore Ts'o wrote:
> The bottom line is that I think we're really "pixel peeping" at this
> point --- which is what obsessed digital photographers will do when
> debating the quality of a Canon vs Nikon DSLR by blowing up a photo by
> a thousand times, a
Hi Ted,
On Thu, 2016-12-22 at 00:41 -0500, Theodore Ts'o wrote:
> On Thu, Dec 22, 2016 at 03:49:39AM +0100, Jason A. Donenfeld wrote:
> >
> > Funny -- while you guys were sending this back & forth, I was writing
> > my reply to Andy which essentially arrives at the same conclusion.
> > Given that
On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa
wrote:
> following up on what appears to be a random subject: ;)
>
> IIRC, ext4 code by default still uses half_md4 for hashing of filenames
> in the htree. siphash seems to fit this use case pretty good.
I saw this too. I'll try to address it
On 22.12.2016 14:10, Jason A. Donenfeld wrote:
> On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa
> wrote:
>> following up on what appears to be a random subject: ;)
>>
>> IIRC, ext4 code by default still uses half_md4 for hashing of filenames
>> in the htree. siphash seems to fit this use ca
On Thu, Dec 22, 2016 at 4:05 PM, Hannes Frederic Sowa
wrote:
> This change would need a new version of the ext4 super block, because
> you should not change existing file systems.
Right.
As a first step, I'm considering adding a patch to move halfmd4.c
inside the ext4 domain, or at the very leas
On Thu, Dec 22, 2016 at 4:12 PM, Jason A. Donenfeld wrote:
> As a first step, I'm considering adding a patch to move halfmd4.c
> inside the ext4 domain, or at the very least, simply remove it from
> linux/cryptohash.h. That'll then leave the handful of bizarre sha1
> usages to consider.
Specifica
On Thu, 2016-12-22 at 16:29 +0100, Jason A. Donenfeld wrote:
> On Thu, Dec 22, 2016 at 4:12 PM, Jason A. Donenfeld wrote:
> > As a first step, I'm considering adding a patch to move halfmd4.c
> > inside the ext4 domain, or at the very least, simply remove it from
> > linux/cryptohash.h. That'll th
Hi Hannes,
On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa
wrote:
> IPv6 you cannot touch anymore. The hashing algorithm is part of uAPI.
> You don't want to give people new IPv6 addresses with the same stable
> secret (across reboots) after a kernel upgrade. Maybe they lose
> connectivity
On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote:
> Hi Hannes,
>
> On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa
> wrote:
> > IPv6 you cannot touch anymore. The hashing algorithm is part of uAPI.
> > You don't want to give people new IPv6 addresses with the same stable
> > secr
On Thu, Dec 22, 2016 at 4:51 PM, Hannes Frederic Sowa
wrote:
> This algorithm should be a non-seeded algorithm, because the hashes
> should be stable and verifiable by user space tooling. Thus this would
> need a hashing algorithm that is hardened against pre-image
> attacks/collision resistance,
On Thu, Dec 22, 2016 at 02:10:33PM +0100, Jason A. Donenfeld wrote:
> On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa
> wrote:
> > following up on what appears to be a random subject: ;)
> >
> > IIRC, ext4 code by default still uses half_md4 for hashing of filenames
> > in the htree. siphash
On Thu, Dec 22, 2016 at 07:03:29AM +0100, Jason A. Donenfeld wrote:
> I find this compelling. We'll have one csprng for both
> get_random_int/long and for /dev/urandom, and we'll be able to update
> that silly warning on the comment of get_random_int/long to read
> "gives output of either rdrand qu
Hi Ted,
On Thu, Dec 22, 2016 at 4:58 PM, Theodore Ts'o wrote:
> Can we do this as a separate series, please? At this point, it's a
> completely separate change from a logical perspective, and we can take
> in the change through the random.git tree.
>
> Changes that touch files that are normally
On Thu, Dec 22, 2016 at 05:16:47PM +0100, Jason A. Donenfeld wrote:
> Could you offer a bit of advice on how to manage dependencies between
> patchsets during merge windows? I'm a bit new to the process.
>
> Specifically, we how have 4 parts:
> 1. add siphash, and use it for some networking code.
On Thu, Dec 22, 2016 at 5:30 PM, Theodore Ts'o wrote:
> I'd do this first, as one set. Adding a new file to crypto is
> unlikely to cause merge conflicts.
Ack.
>
>> 2. convert char/random to use siphash. to: ted ts'o's random-next
>
> I'm confused, I thought you had agreed to the batched chacha
On 22.12.2016 16:54, Theodore Ts'o wrote:
> On Thu, Dec 22, 2016 at 02:10:33PM +0100, Jason A. Donenfeld wrote:
>> On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa
>> wrote:
>>> following up on what appears to be a random subject: ;)
>>>
>>> IIRC, ext4 code by default still uses half_md4 for
On Thu, Dec 22, 2016 at 7:08 PM, Hannes Frederic Sowa
wrote:
> I wasn't concerned about performance but more about DoS resilience. I
> wonder how safe half md4 actually is in terms of allowing users to
> generate long hash chains in the filesystem (in terms of length
> extension attacks against ha
On Thu, Dec 22, 2016 at 07:08:37PM +0100, Hannes Frederic Sowa wrote:
> I wasn't concerned about performance but more about DoS resilience. I
> wonder how safe half md4 actually is in terms of allowing users to
> generate long hash chains in the filesystem (in terms of length
> extension attacks ag
On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa
wrote:
> On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote:
>> Hi Hannes,
>>
>> On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa
>> wrote:
>> > IPv6 you cannot touch anymore. The hashing algorithm is part of uAPI.
>> > You don't
Hi all,
I don't know what your design requirements are for this. It looks like
you're generating some kind of crypto digest of a program, and you
need to avoid collisions. If you'd like to go with a PRF (keyed hash
function) that uses some kernel secret key, then I'd strongly suggest
using Keyed-B
On Thu, Dec 22, 2016 at 8:28 AM, Jason A. Donenfeld wrote:
> Hi all,
>
> I don't know what your design requirements are for this. It looks like
> you're generating some kind of crypto digest of a program, and you
> need to avoid collisions. If you'd like to go with a PRF (keyed hash
> function) th
On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote:
> On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa
> wrote:
> > On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote:
> > > Hi Hannes,
> > >
> > > On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa
> > > wrote:
> > > > IPv6
On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa
wrote:
> On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote:
>> On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa
>> wrote:
>> > On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote:
>> > > Hi Hannes,
>> > >
>> > > On Thu, Dec
On Thu, 2016-12-22 at 09:25 -0800, Andy Lutomirski wrote:
> On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa
> wrote:
> > On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote:
> > >
> > > You mean:
> > >
> > > commit 7bd509e311f408f7a5132fcdde2069af65fa05ae
> > > Author: Daniel Borkmann
On Thu, Dec 22, 2016 at 5:59 PM, Hannes Frederic Sowa
wrote:
> We don't prevent ebpf programs being loaded based on the digest but
> just to uniquely identify loaded programs from user space and match up
> with their source.
Okay, so in that case, a weak hashing function like SHA1 could result
in
On Thu, Dec 22, 2016 at 9:25 AM, Andy Lutomirski wrote:
> On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa
> wrote:
>> On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote:
>>
>> We don't prevent ebpf programs being loaded based on the digest but
>> just to uniquely identify loaded progr
On Thu, Dec 22, 2016 at 11:34 AM, Alexei Starovoitov
wrote:
> On Thu, Dec 22, 2016 at 9:25 AM, Andy Lutomirski wrote:
>> On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa
>> wrote:
>>> On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote:
>>>
>>> We don't prevent ebpf programs being load
On 22.12.2016 20:56, Andy Lutomirski wrote:
> It's also not quite clear to me why userspace needs to be able to
> calculate the digest on its own. A bpf(BPF_CALC_PROGRAM_DIGEST)
> command that takes a BPF program as input and hashes it would seem to
> serve the same purpose, and that would allow t
On 12/22/2016 05:59 PM, Hannes Frederic Sowa wrote:
On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote:
On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa
wrote:
On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote:
On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa
wrote:
On 12/22/2016 06:25 PM, Andy Lutomirski wrote:
On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa
[...]
I wondered if bpf program loading should have used the module loading
infrastructure from the beginning...
That would be way too complicated and would be nasty for the unprivileged cases
On Fri, 2016-12-23 at 11:04 +0100, Daniel Borkmann wrote:
> On 12/22/2016 05:59 PM, Hannes Frederic Sowa wrote:
> > On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote:
> > > On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa
> > > wrote:
> > > > On Thu, 2016-12-22 at 16:41 +0100, Jason A.
On 12/23/2016 11:59 AM, Hannes Frederic Sowa wrote:
On Fri, 2016-12-23 at 11:04 +0100, Daniel Borkmann wrote:
On 12/22/2016 05:59 PM, Hannes Frederic Sowa wrote:
On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote:
[...]
The hashing is not a proper sha1 neither, unfortunately. I think th
On Fri, Dec 23, 2016 at 3:59 AM, Daniel Borkmann wrote:
> On 12/23/2016 11:59 AM, Hannes Frederic Sowa wrote:
>>
>> On Fri, 2016-12-23 at 11:04 +0100, Daniel Borkmann wrote:
>>>
>>> On 12/22/2016 05:59 PM, Hannes Frederic Sowa wrote:
On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wro
On Fri, Dec 23, 2016 at 8:23 AM, Andy Lutomirski wrote:
> On Fri, Dec 23, 2016 at 3:59 AM, Daniel Borkmann wrote:
>> On 12/23/2016 11:59 AM, Hannes Frederic Sowa wrote:
>>>
>>> On Fri, 2016-12-23 at 11:04 +0100, Daniel Borkmann wrote:
On 12/22/2016 05:59 PM, Hannes Frederic Sowa wrote:
On 23.12.2016 17:42, Andy Lutomirski wrote:
> On Fri, Dec 23, 2016 at 8:23 AM, Andy Lutomirski wrote:
>> On Fri, Dec 23, 2016 at 3:59 AM, Daniel Borkmann
>> wrote:
>>> On 12/23/2016 11:59 AM, Hannes Frederic Sowa wrote:
On Fri, 2016-12-23 at 11:04 +0100, Daniel Borkmann wrote:
>
>>
On Fri, Dec 23, 2016 at 7:19 PM, Hannes Frederic Sowa
wrote:
> Factoring out sha3
Per the other thread, you probably don't actually want SHA3, because
it's slow in software. You want SHA2. If you want something faster and
better, then Blake2 is most certainly the way to go. I'll be
submitting som
37 matches
Mail list logo