On Thu, Jan 26, 2006 at 10:45:10AM -0500, Paul Thorn wrote:
> On Thu, 26 Jan 2006, Joachim Schipper wrote:
>
> >On Wed, Jan 25, 2006 at 10:40:44AM -0500, Paul Thorn wrote:
> >>Hi,
<snipped by Paul: Paul wants to have an encrypted fs on DVD, but the
isofs tools don't like it>
> >>I'm open to any suggestions on how else this might be most easily
> >>accomplished.
> >
> >I don't know about the specific application, but since DVDs are
> >read-only anyway, and encrypted data tends not be accessed that often,
> >is there a good reason not to just pipe tar into gpg? That works very
> >well, and very portably.
>
> I was trying to avoid encrypting individual files on the DVD.
> Otherwise, to retrieve and use the files involves a local copy. If
> possible, I'd prefer to access the DVD as a filesystem (even
> at the cost of speed -- or complexity to mount it) if this is at
> all possible.
>
> While the tar method would work if I split the data into smaller
> segments, retrieval would be cumbersome at best, I fear. The
> resulting encrypted tar files would need to be significantly < 4GB
> for the same reasons that the large vnd filesystem can't be written
> to the disk (ISO doesn't like these large files).
>
> These files may need to be accessed somewhat regularly, so I was
> looking for some method that is reasonably secure, but not
> overly cumbersome for someone authorised to access.
>
> Thanks for the suggestion, though. I'll probably be able to use
> something like this for encrypting pure backups that are less
> likely to be used regularly.
I seem to recall there being versions of the cdrecord suite that worked
for large files as well[1]. Of course, getting them to run or even compile
on OpenBSD might not be trivial.
A last resort is always to simply use a couple of files, and mount them
in the proper order. Depending on how hackish you wish to be, either
overlapping mounts or mounts on subdirectories, and a simple script to
set it all up and tear it all down, most of the complexity of this setup
can be well-hidden from the actual user.
In fact, with a proper script to burn the CD, most of the complexity can
be hidden from the creator, too.
This should not be too much of a problem; make the files ~ 1 GB in size
each, and call them /fses/a.fs, /fses/b.fs, /fses/c.fs, and /fses/d.fs.
Any file that takes up more than, say, a couple of hundreds of megs can
be archived individually[2][3]; a good script will decrypt these to a
pre-mounted encrypted filesystem on the host (either that, or mfs - as
mfs uses swap, not regular disk space, in addition to conventional
memory of course, and swap is encrypted by default on OpenBSD 3.8,
copying to an mfs filesystem should be safe - unless you mucked with the
vm.swapencrypt.enable sysctl, or are using an older version, or fail to
get the permissions right).
Joachim
[1] Maybe using UDF? I can't recall any details, I'm afraid, as I was
not terribly interested at the time.
[2] There is a tradeoff here, as putting as much as possible in a
filesystem will ease the load on a host that is reading it, while
putting large files into a tar archive or burning them separately will
save some space - especially when using simple algorithms for dividing
the files over the filesystems.
[3] Extremely large files may need to be split, even.
