trampCrypt family of CLI programs

[vedaal at nym.hush.com]

On Wed, 01 Aug 2012 15:04:57 -0400 peter.segment at wronghead.com 
wrote:
>On 31/07/12 19:25, Robert J. Hansen - rjh at sixdemonbag.org wrote:

>Alice doesn't understand what a certificate is and hasn't got the
>time necessary to do so. 

So, 
she, and others like her, would be *more at risk* for compromise by 
any attacker who might take advantage of this, and of the knowledge 
that she would be communicating sensitive information over a semi-
public setup that she believes to be protective of her privacy.

 -----

>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.

 ...

>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.

 -----

I am not familiar with TrampCrypt, and cannot offer any guidance 
about it, but here are some speculations about how you might 
accomplish your goals, with the caveat that you accept all the 
risks involved,
(and, communicating those risks to whoever is trusting your advice 
and allowing their sensitive information to be communicated.) :

[1] Setup gnupg on a usb disk, and boot the adhoc computer from a 
static cd or dvd (e.g., an Ubuntu install disk to run in 'demo' 
mode.

[2] The Ubuntu Demo can read files on the adhoc computer, both in 
linux,
FAT, and NTFS systems, (and can even access any file on a windows 
system, without any administrative privilege necessary).

[3] Create a hierarchy of users who wish to communicate with each 
other,
and give them all the same password,  (a random string of 
sufficient length that the users will need to write down.  A simple 
way to do this, is to encrypt any file with gnupg, and then decrypt 
using the option of '--show-session-key' , and using the session 
key string as the passphrase, and then supplying it to all users of 
this hierarchy.)

[4] Encryption and decryption of files can then be done 
symmetrically, by the users, with very minimal effort.
(i) To encrypt:  gpg -c -a filename
(ii) To decrypt: gpg encrypted filename
(it's not necessary to use a specific 'decrypt' command, gpg will 
'understand' from the file that it's encrypted and ask the user for 
the passphrase).

[5] If a user wants to communicate with users from other 
hierarchies, give that user the passphrase for that hierarchy, and 
impress upon the user to 'not get the passphrases mixed up'.  ;-)

All unencrypted data will be written only to the usb.

This system is doable but has 'many' potential flaws, of which only 
a few are listed here:

-keyloggers capturing everything by someone targeting the adhoc 
computer.

-malware attacks on the usb, if used for any purpose on any other 
computer.

-exposure of sensitive information if the usb is lost or stolen.

-losing the written passhrase, or, worse, having it copied without 
the user's knowledge.


Here is a site on how to build a standalone gnupg on a usb:

(If you want to, you can put this on a usb with a bootable ubuntu 
system and boot directly from the usb, if you adhoc computers allow 
for this).

http://www.angelfire.com/mb2/mbgpg2go/tp.html

Final, (and most important), caveat:

You are the judge of what your threat model is, and what the 
potential risks you are subjecting the unsuspecting users to.

These users are *trusting* you with their sensitive information, 
but are *blind* as to the problems that may occur.

It is far, far worse to communicate using encryption, expecting 
that privacy will be maintained, when unknown  to the user, it may 
not be, 
than not to communicate at all.

Do not place such a 'stumbling block' before the 'blind'.


vedaal

(sorry about breaking the thread :-((
posted from an area where i can't use thunderbird)