freebsd security - Jul 2005 - Kernel Source Divergence, Security (was: booting gbde-encrypted filesystem)

In message <20050731135919.GA43753@afields.ca>, Allan Fields writes:
>Yes, this is all very nice, but when is someone actually going to
>commit it? ;)
I'm (as always) short of time, and GBDE is not the top priority
for me for the time being.

So I am more than happy to see people band together and improve
gbde.

The main work necessary is to polish the userland program and that
is relatively trivial programming, so anyone should be able to pick
that up: just go for it.

Giving gbde a taste function so that the root filesystem can be
protected by GBDE, this is also OK by me in principle, but I'd like
to review the patch before it gets committed because there are a
large number of dragons.

In P4:phk_gbde there is the beginning of hw-crypto support through
opencrypto(9), if somebody wants to work on that, get in touch with
me.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

On Sun, Jul 31, 2005 at 04:07:27PM +0200, Poul-Henning Kamp wrote:
+> In message <20050731135919.GA43753@afields.ca>, Allan Fields writes:
+> 
+> >Yes, this is all very nice, but when is someone actually going to
+> >commit it? ;)
+> 
+> I'm (as always) short of time, and GBDE is not the top priority
+> for me for the time being.
+> 
+> So I am more than happy to see people band together and improve
+> gbde.
+> 
+> The main work necessary is to polish the userland program and that
+> is relatively trivial programming, so anyone should be able to pick
+> that up: just go for it.
+> 
+> Giving gbde a taste function so that the root filesystem can be
+> protected by GBDE, this is also OK by me in principle, but I'd like
+> to review the patch before it gets committed because there are a
+> large number of dragons.
+> 
+> In P4:phk_gbde there is the beginning of hw-crypto support through
+> opencrypto(9), if somebody wants to work on that, get in touch with
+> me.

I'm starting to wonder if we couldn't create one storage-crypto-base
and rewrite gbde, geli on top of it.
geli(8) is complete, ie. you can use any command on attached and
detached providers, you can backup your metadata, protect your passphrase
with PKCS#5v2, use files as a key part, etc.
gbde(8) (userland tool) is not finished (all those things I've in
geli already are on its todo list).

I've plan for another crypto-storage class, which will provide privacy
and integrity verification (the very thing we are missing now).
I want another class, because it will be slower than geli in both
crypto-time and disk-access-time aspects.
Another possibility is to integrate two classes and allow user to
decide if he wants privacy, integrity verification or both.

If someone can spend time on integreting gbde crypto scheme into geli
where userland part is complete, where crypto(9) is used already, etc.
that'd be cool.
The truth is, that the main difference between gbde/geli is how crypto is
used on disk, the other elements (managing keys, protecting passphrases,
metadata backups, encrypted root partition, etc.) are or could be the same.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd@FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-security/attachments/20050731/acc491ea/attachment.bin