I've a need to have compressed vnds which aren't easily readable except by 
the target system. The target system will vary in spec, but could be as 
low as P100, 64MB RAM. I can think of a few scenarios:

1) makefs > vncompress > bdes encrypt. On target, bdes decrypt to mfs 
and run from there (currently using this)

Pros:	easy to generate
 	one-time decryption (so no per-access overhead)
 	No kernel size overhead
Cons:	Expensive on RAM

2) makefs (to get image size for cgd) > make cgd in vnd > copy data > 
vncompress. Run in-situ on target

Pros:	No RAM overhead
Cons: 	cgd data won't compress well
 	kernel overhead for cgd
 	Per-access overhead
 	Potentially computationally heavy on low-end machine

3) As 2), but attempt to reverse order of cgd and vncompress

Pros:	As 2), but should compress much better.
Cons:	As 2), plus is it even possible?

4) makefs, vncompress, some form of basic encryption. Extend vnd to be 
able to decrypt on fly before passing to uncompression.

Somewhere in compstrategy() in dev/vnd.c looks like the right place, just 
before the /* uncompress the buffer */ line (row 1663).

Encryption could be similar to bdes or perhaps something more simple (even 
EORing a repeated key).

Pros:	Could hardwire key at compile time in kernel
 	Lightweight encryption not a big computational overhead
 	Little kernel size overhead
 	Will compress well
 	No RAM overhead
Cons:	Requires kernel hacking
 	Does vnd's file access mechanisms allow this to be slotted in?

Option 4) seems best to me for my particular purposes. Thoughts?

(Please CC: me in on replies)

-- 
Stephen