trampCrypt family of CLI programs

[peter.segment at wronghead.com]

On 31/07/12 19:25, Robert J. Hansen - rjh at sixdemonbag.org wrote:

> Set up a trusted introducer/certificate authority and presto, bang,
> you're off to the races.  When Alice comes on board at the company, the
> local authority generates a certificate for her, sets up her
> Thunderbird+Enigmail installation

Alice doesn't understand what a certificate is and hasn't got the
time necessary to do so. More importantly, she hasn't got a 
Thunderbird+Enigmail installation and has no intention of getting
one (or anything else that needs to "be installed") on each and
every computer on which she performs the tasks requiring the
software tool we are searching for here. Alice wants to plug a
USB stick into a computer, *any computer*, and start a CLI program
with something like:

trampEncrypt -myKey=xyz.bin -key=bob.bin cleartext.file ciphertext.file

or:

trampDecrypt -myKey=xyz.bin ciphertext.file cleartext.file

In either case, the program will ask for the pass-phrase to decrypt
xyz.bin, and, in case of encryption, some entropy key-presses.

(The third program, trampKeygen, will be executed only in controlled
environment).

(Add a -text flag for trampEncrypt to pre-compress plaintext and
produce base64 encoded ciphertext and vise versa for trampDecrypt
and that pretty well completes the functional specs.)

 > In order to communicate securely with someone outside the 
organization, she calls up the certificate authority...

The hypothetical benefit of secure communication with the "general
public", i.e., non-members of the group is not considered here.
There is no benefit of key file internal structure conformance to
pgp/gpg or end-user algorithm choice.

 > You must have physical control over the hardware for GnuPG to be used
 > safely.  "Drive-by" machines have uncomfortably high malware infection
 > rates.  Don't use GnuPG except on machines that you physically control
 > and are confident are free of malware.

Assume, please, that the requirement to use the software on multiple
ad-hoc computers is quite "hard". I won't get into what these may or may 
not be here; but it has been determined that in this case the risk
is quite low, while the operational flexibility is invaluable.

Perhaps as an aside...: I have no doubt whatsoever that the total
population of MS Windows computers owned and operated as his or her
"trusted machine" by an average gpg user has a much, much greater
malware infection rate than ad-hoc computers to be used by the
members of this group. Yet somehow, malware is not considered a
problem worth addressing by gpg architects and use experts - as it
indeed shouldn't be. However, it is invariably used to quickly
trump any requests for a "gpg-portable" variant. Why is that so?

Much as I appreciate all comments provided, I can't help but
observe that those offered so far mostly debate the wisdom of the
requirements and not speculating on the best way to satisfy them.
For instance, what is the feasibility of "scissoring out" just the 
required functionality from the gpg code base and then wrap it into
three CLI programs (trampKeygen, trampEncrypt, trampDecrypt)?
(trampSign and trampVerify could be added if there is ever any
need for signing identified by this - or some other group of
trumpCrypt family of CLI programs).

Is there perhaps a previous version (pre-"agent", specifically) that
would be a better candidate for such an endevour? Are there any
security implications that one should watch out for in earlier
versions of crypto primitives in gpg code base?

Peter M.