vedaal at nym
Aug 1, 2012, 3:13 PM
Post #3 of 6
On Wed, 01 Aug 2012 15:04:57 -0400 peter.segment [at] wronghead
>On 31/07/12 19:25, Robert J. Hansen - rjh [at] sixdemonbag wrote:
>Alice doesn't understand what a certificate is and hasn't got the
>time necessary to do 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
>ad-hoc computers is quite "hard". I won't get into what these 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
(and, communicating those risks to whoever is trusting your advice
and allowing their sensitive information to be communicated.) :
 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'
 The Ubuntu Demo can read files on the adhoc computer, both in
FAT, and NTFS systems, (and can even access any file on a windows
system, without any administrative privilege necessary).
 Create a hierarchy of users who wish to communicate with each
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
 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
 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
-malware attacks on the usb, if used for any purpose on any other
-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
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
than not to communicate at all.
Do not place such a 'stumbling block' before the 'blind'.
(sorry about breaking the thread :-((
posted from an area where i can't use thunderbird)
Gnupg-users mailing list
Gnupg-users [at] gnupg