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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20141206233200.3175.qmail@ns.horizon.com> Date: 6 Dec 2014 18:32:00 -0500 From: "George Spelvin" <linux@...izon.com> To: darrick.wong@...cle.com, linux@...izon.com Cc: linux-ext4@...r.kernel.org, tytso@....edu Subject: Re: [PATCH v1 4/10] lib/siphash.c: New file On Mon, Sep 229 2014 at 12:12:43 -0700, Darrick J. Wong wrote: > Could you please make this part of crypto/ so that anyone who wants to > improve upon the C implementation (Google suggests that SSE/AVX ports > are possible) can do so easily? Well, *that* was a rabbit hole. It seems like an obviously good idea, but let's just say that crypto/ is non-obvious. (No, it didn't take me 2 months of work; I just got sidetracked a lot because it was discouraging.) But now that my cleanup patches there are getting reviewed, I can answer. Basically, to fit into the crypto layer would require a very different implementation with a lot more overhead. The code I proposed is optimized for both size and performance in the single-contiguous-small-buffer case that apples to file names. There's are no separate init/update/final calls, no saving internal state to memory, no handling of discontiguous input buffers, etc. This is all because SipHash is designed to be *extremely* lightweight, so the overhead of marshalling the input bytes is noticeable. I could easily write a *separate* implementation for crypto/, and it could share source code, but it wouldn't be the same object code. > This would also make it so that ext4 only loads the algorithm when necessary. Yes, but my Cunning Plan is to replace the MD5 use in net/core_secure_seq.c with this, too. And, after careful consultation with Ted, the one in get_random_int, too. With all the simplifying assumptions I mentioed above made specifically in order to get it down to negligible size, the code is 454 bytes long with -O2, 397 bytes with -Os. Is that worth the overhead of a separate module? -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists