Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: GnuPG: users

trampCrypt family of CLI programs

 

 

GnuPG users RSS feed   Index | Next | Previous | View Threaded


peter.segment at wronghead

Aug 1, 2012, 2:37 AM

Post #1 of 6 (427 views)
Permalink
trampCrypt family of CLI programs

On 31/07/12 19:25, Robert J. Hansen - rjh [at] sixdemonbag 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.



_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


rjh at sixdemonbag

Aug 1, 2012, 12:22 PM

Post #2 of 6 (411 views)
Permalink
Re: trampCrypt family of CLI programs [In reply to]

On 8/1/2012 5:37 AM, peter.segment [at] wronghead wrote:
> Alice doesn't understand what a certificate is and hasn't got the
> time necessary to do so.

Pardon me for being blunt: she's boned.

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

I've read this a few times and I don't understand the point you're
trying to make, I'm sorry.

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

If you'll only consider 'authoritative' sources, Werner has said several
times that so-called 'portable' GnuPG installations are too prone to
malware for him to recommend using them. (I don't recall if his
reasoning is "USB tokens are malware vectors and if you go about
plugging your token into strange computers you'll be sorry", or "any
computer that lets strangers plug in USB tokens is probably already
compromised, so don't use them or you'll be sorry." It is quite
possibly both.) I've heard similar remarks from other people. You may
find a brief perusal of the archives to be very illuminating.

Further, malware is a very real concern for GnuPG's architecture. For
example, consider GPGME: rather than have a shared library that can be
hijacked by Process A (i.e., malware) to compromise Process B's
security, GPGME spawns an entirely new GnuPG invocation and uses the
process barrier to help keep malware from propagating into the core.
Malware is also one of the reasons why GnuPG supports smart cards: smart
cards are much more resistant to exploitation than is a desktop PC.

> However, it is invariably used to quickly trump any requests for a
> "gpg-portable" variant. Why is that so?

Because it is the consensus of the community, after much deliberation
and consideration. Some members of the community disagree and have done
some good work making portable GnuPG installations: perhaps some of them
will be in touch with you to share their knowledge.

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

You may, of course, do this yourself; the licensing explicitly permits
it. However, I won't do this for you because I think it's a bad idea
and you haven't persuaded me otherwise. I imagine many of the people
who are competent to do this work are of a similar mind.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


vedaal at nym

Aug 1, 2012, 3:13 PM

Post #3 of 6 (412 views)
Permalink
Re: trampCrypt family of CLI programs [In reply to]

On Wed, 01 Aug 2012 15:04:57 -0400 peter.segment [at] wronghead
wrote:
>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.

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)


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


rjh at sixdemonbag

Aug 1, 2012, 4:05 PM

Post #4 of 6 (413 views)
Permalink
Re: trampCrypt family of CLI programs [In reply to]

On 8/1/2012 6:13 PM, vedaal [at] nym wrote:
> 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.

I would say that it "may be far, far worse," but with that minor quibble
I could not agree more.

=====

By itself, GnuPG is useless. It may even be worse than useless. In the
best case GnuPG can be an effective tool for ensuring the
confidentiality and integrity of messages, but in the worst case it's
just cryptographic fairy dust: people think that if they just do X
followed by Y and Z, they will somehow magically be secure.

Feynman warned against this thinking in science. He called it
"cargo-cult science," after the South Pacific islanders who built
incredibly intricate religions based on imitating the forms of
airplanes, airbases and other things they saw during World War Two. But
no matter how accurate the bamboo mock-up of a DC-3 cargo plane is,
without an understanding of Bernoulli's Principle, the Navier-Stokes
equations, fluid dynamics, mechanical engineering, Newtonian mechanics
and the like, you can't make a real DC-3 and your bamboo mock-up will
remain something that *looks* like a DC-3 while missing absolutely
everything that makes a real DC-3 what it is.

Cargo-cult cryptography is the exact same thing, just done with software
instead of bamboo.

=====

What makes cargo-cult DC-3 airplanes safe is the fact they never get
airborne. We know they are clearly, obviously, defective from the
get-go, and so we never trust them. We might fool ourselves into
thinking we're on the right track and next year's bamboo DC-3 will be
able to take off to fly to John Frum [1] for sure, but this year's plane
is just not working. Nobody really gets hurt.

But cryptography is not like an airplane, where the fake stuff becomes
evident very early on. Cryptography is more like an ejection seat.
When you need it, it has to work right, the first time, even while the
aircraft is on fire, breaking up, and about to explode... and even then,
if you go into it without training, you'll probably be dead before you
hit the ground.

The popular understanding of an ejection seat -- "pull the D-rings and
enjoy the ride" -- is completely wrong. Pilots have to train for
ejection because there are so many things that can screw up. You have
to get into the right position for ejection because otherwise you'll
shatter your spinal column from the 35+ Gs of acceleration. And once
you've ejected, with your vertebrae cracked and/or broken, you have to
consider the possibility you may be on fire. (Seriously. You were
sitting on top of a rocket motor inside an aircraft that was on fire and
about to explode. You may be on fire.)

What do you do then?

Your shroud lines may get tangled. How do you untangle them? How do
you untangle them with a broken spinal column and your boots on fire?

You may be about to land in hostile territory, injured, and with an army
hunting you. How do you hide and how do you evade?

The purpose of training is not to give you rote tools. The purpose of
training is to teach you how these rote tools work, how to use them in
concert, when one tool is disadvised and another is strong, when two
tools can be combined in creative ways, and so forth. It is to give you
the ability to improvise highly effective solutions to the demands of a
chaotic and ever-changing world.

Pilots call their training "training," and call their knowledge of how
to use their training "the Right Stuff."

In communications security, knowing how to use training is called
"tradecraft." [2]

=====

Whenever I hear someone say that GnuPG is too hard to use, well, I
sympathize with them. GnuPG is very hard to use. It has a learning
curve like the Matterhorn. I have no disagreement there.

But when I hear people say they have a great idea that will allow people
to keep secure against dedicated, serious adversaries while requiring
very little training or knowledge on the part of the user, well...

There is no replacement for tradecraft.

There will never be a replacement for tradecraft.

Tradecraft is always a hard skill to acquire. (I am a rank amateur, and
I doubt many people on this list are better.)

And you can rely on a dedicated, serious adversary having excellent
tradecraft of their own.







[1] http://en.wikipedia.org/wiki/John_Frum
[2] http://en.wikipedia.org/wiki/Tradecraft


_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


MichaelQuigley at TheWay

Aug 2, 2012, 5:30 AM

Post #5 of 6 (406 views)
Permalink
Re: trampCrypt family of CLI programs [In reply to]

gnupg-users-bounces [at] gnupg wrote on 08/02/2012 04:35:31 AM:

> ----- Message from peter.segment [at] wronghead on Wed, 01 Aug 2012
> 09:37:35 +0000 -----
>
> To:
>
> gnupg-users [at] gnupg
>
> Subject:
>
> trampCrypt family of CLI programs
>
> On 31/07/12 19:25, Robert J. Hansen - rjh [at] sixdemonbag 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.
. . .
. . .
. . .

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

She needn't understand a certificate. When she joins "the trusted
introducer/certificate authority" sets it up for her. I don't follow how
she gets confused by a certificate she need not understand, yet she can
remember then correctly and consistently type the commands you've outlined
above.


reynt0 at cs

Aug 2, 2012, 6:01 PM

Post #6 of 6 (403 views)
Permalink
Re: trampCrypt family of CLI programs [In reply to]

On Wed, 1 Aug 2012, Robert J. Hansen wrote:
. . .
> Feynman warned against this thinking in science. He called it
> "cargo-cult science," after the South Pacific islanders who built
. . .

Really excellent. Thanks for taking the time to contribute
so much detail elucidating the metaphor so well.

Notwithstanding that, I can imagine that the original
poster's interest might be not entirely inappropriate in
say some high-flux situation or similar.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users

GnuPG users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.