Hello,
I'm running 4.4-RELEASE and I'm changing the vn(4) driver to do
transparent data encryption (for now it's a lame XOR algorithm,
but that's not forever; I once made it to run with CAST128 from
the crypto libs, and fell back just to sort out problem No 2
below). My questions are:
1) Am I reinventing the wheel? Don't tell me about cfs, though.
I know that something concerning cryptography is going to get
into 4.8-R kernel from OpenBSD, but what will it look like?
2) After I disklabel it according to the vnconfig man page and
newfs it (I can even successfully fsck it), it won't mount stating
it has an incorrect superblock. fsck -b ... doesn't help (though
states it's all ok). It's the same with XOR and CAST. When I use
the original version of vn, and do _everything_ the same way, it
works (mounts).
Ordinary reads from and writes to the encrypted vn0 go ok, e.g.
# cat /dev/urandom|tee foo/dev/vn0
makes a file foo identical to /dev/vn0 (though the file which is
backing vn0 is encrypted).
If you need the diff, just tell me. But the changes are so
straightforward (directing read and write routines in vn_cdevsw
to two routines doing the crypto and calling physread/write
appropriately) that I can't think of a way it could fail...
Am I not processing _all_ the reads/writes?
3) Does anyone (except for me) need it? (I'm going to change
vnconfig too, otherwise we'll store the key in the 'door';)
4) Is hackers@ a better place for discussion?
Any suggestions welcome.
DoubleF
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message
