From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from v6.tansi.org (ns.km31936-01.keymachine.de [87.118.116.4]) by mail.saout.de (Postfix) with ESMTP for ; Sun, 9 Mar 2014 21:25:49 +0100 (CET) Received: from gatewagner.dyndns.org (77-57-44-24.dclient.hispeed.ch [77.57.44.24]) by v6.tansi.org (Postfix) with ESMTPA id DBF8E34FA001 for ; Sun, 9 Mar 2014 21:15:41 +0100 (CET) Date: Sun, 9 Mar 2014 21:15:40 +0100 From: Arno Wagner Message-ID: <20140309201540.GA26572@tansi.org> References: <20140309174247.GA1752@fancy-poultry.org> <531CAC7E.2050805@gmail.com> <20140309183204.GA2999@fancy-poultry.org> <531CC69E.8000300@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <531CC69E.8000300@gmail.com> Subject: Re: [dm-crypt] SHAx and LUKS/cryptsetup List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On Sun, Mar 09, 2014 at 20:53:02 CET, Milan Broz wrote: > On 9.3.2014 19:32, Heinz Diehl wrote: > >On 09.03.2014, Milan Broz wrote: > > > >>If you are using kernel backend (not gcrypt one) > > > >I do :-) > > > >>sha1 is used as test that interface works. > > > >Ok, all good! So this is it. Thanks a lot! > > Just to clarity it little bit: > > Kernel userspace crypto API was (and still is) quite undocumented, This is one thing I really do not understand. Doing crypto right is already hard. With bad documentation it gets worse. Yet the documentation for kernel, OpenSSL, commercial libraries I have looked at, Java API, etc. is bad. (for Java so bad that recently 30'000 Apps on Android were insecure). I really do not get it. Systematic sabotage of the documentation seems unlikely, even after Snowden, so I can only conclude many people implementing crypto have a problem writing documentation. > and testing SHA1 (which is mandatory > for LUKS backend support) was the simplest way how > to verify kernel backend works reliably. > (In some kernel versions it was impossible to check if just algorithm > is missing or the whole kernel socket interface is not available.) > > It actually does not compute any sha1 hash, it just tries > to initialize it. > > BTW I found some problems with kernel backend so use with care. Bad documentation and unreliable. Urgh. > One problem is e.g. backend cannot use longer > key for HMAC than 20480 bytes (at least on my 32bit VM), > which can cause problems for larger keyfiles in PBKDF2. > > I have workaround for this but will need some time to finish > it (I do not want to touch internal PBKDF2 without adding test > vectors and other tests.) Very sensible. I completely support this approach. Arno > > Milan > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. - Plato