linux-kernel - Re: [PATCH v6 1/4] crypto: AF

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2836726.omC5yx5ZyR@tachyon.chronox.de>
Date:	Tue, 30 Dec 2014 22:03:33 +0100
From:	Stephan Mueller <smueller@...onox.de>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	Daniel Borkmann <dborkman@...hat.com>,
	'Quentin Gouchet' <quentin.gouchet@...il.com>,
	'LKML' <linux-kernel@...r.kernel.org>,
	linux-crypto@...r.kernel.org, linux-api@...r.kernel.org
Subject: Re: [PATCH v6 1/4] crypto: AF_ALG: add AEAD support

Am Dienstag, 30. Dezember 2014, 04:33:41 schrieb Herbert Xu:

Hi Herbert,

> 
> > > PS we should add a length check for missing/partial auth tags
> > > to crypto_aead_decrypt.  We can then remove such checks from
> > > individual implementations.
> > 
> > I agree in full here. Shall I create such a patch together with the AEAD
> > AF_ALG interface, or can we merge the AEAD without that patch now and
> > create a separate patch later?
> 
> We should at least add a check in crypto_aead_decrypt first so as
> to guarantee nothing slips through.

I have prepared a patch for this which I will release shortly. IMHO that patch 
should not have any significant performance penalty. I will also remove the 
respective check from the algif_aead implementation.

In addition, I would suggest to add a similar check for the encryption 
operation to verify that the ciphertext buffer is at least as large as the 
blocks needed for plaintext plus the memory needed for the auth tag (note, my 
first attempts working with AEAD lead to days of debugging of kernel crashers 
as I did not understand I had too little memory allocated for the ciphertext 
buffer). However, such check needs to traverse all plaintext scatterlist 
entries which may have a noticeable performance hit.

Do you see the need for such check? If yes, do you see a way to avoid 
traversing all plaintext scatterlist entries?

Thanks
-- 
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/