lists.openwall.net | 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
| ||
|
Date: Thu, 13 Jan 2022 12:15:36 +0100 From: Hannes Frederic Sowa <hannes@...essinduktion.org> To: "Jason A. Donenfeld" <Jason@...c4.com>, Toke Høiland-Jørgensen <toke@...hat.com> Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org, Geert Uytterhoeven <geert@...ux-m68k.org>, Herbert Xu <herbert@...dor.apana.org.au>, Ard Biesheuvel <ardb@...nel.org>, Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>, linux-crypto@...r.kernel.org, Erik Kline <ek@...gle.com>, Fernando Gont <fgont@...networks.com>, Lorenzo Colitti <lorenzo@...gle.com>, hideaki.yoshifuji@...aclelinux.com Subject: Re: [PATCH RFC v1 2/3] ipv6: move from sha1 to blake2s in address calculation Hello, On 13.01.22 00:31, Jason A. Donenfeld wrote: > On 1/13/22, Toke Høiland-Jørgensen <toke@...hat.com> wrote: >> However, if we make this change, systems setting a stable_secret and >> using addr_gen_mode 2 or 3 will come up with a completely different >> address after a kernel upgrade. Which would be bad for any operator >> expecting to be able to find their machine again after a reboot, >> especially if it is accessed remotely. >> >> I haven't ever used this feature myself, though, or seen it in use. So I >> don't know if this is purely a theoretical concern, or if the >> stable_address feature is actually used in this way in practice. If it >> is, I guess the switch would have to be opt-in, which kinda defeats the >> purpose, no (i.e., we'd have to keep the SHA1 code around Yes, it is hard to tell if such a change would have real world impact due to not knowing its actual usage in the field - but I would avoid such a change. The reason for this standard is to have stable addresses across reboots. The standard is widely used but most servers or desktops might get their stable privacy addresses being generated by user space network management systems (NetworkManager/networkd) nowadays. I would guess it could be used in embedded installations. The impact of this change could be annoying though: users could suddenly lose connectivity due to e.g. changes to the default gateway after an upgrade. > I'm not even so sure that's true. That was my worry at first, but > actually, looking at this more closely, DAD means that the address can > be changed anyway - a byte counter is hashed in - so there's no > gurantee there. The duplicate address detection counter is a way to merely provide basic network connectivity in case of duplicate addresses on the network (maybe some kind misconfiguration or L2 attack). Such detected addresses would show up in the kernel log and an administrator should investigate and clean up the situation. Afterwards bringing the interface down and up again should revert the interface to its initial (dad_counter == 0) address. > There's also the other aspect that open coding sha1_transform like > this and prepending it with the secret (rather than a better > construction) isn't so great... Take a look at the latest version of > this in my branch to see a really nice simplification and security > improvement: > > https://git.zx2c4.com/linux-dev/log/?h=remove-sha1 All in all, I consider the hash produced here as being part of uAPI unfortunately and thus cannot be changed. It is unfortunate that it can't easily be improved (I assume a separate mode for this is not reasonable). The patches definitely look like a nice cleanup. Would this be the only user of sha_transform left? Bye, Hannes
Powered by blists - more mailing lists