[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-crypto
Subject:    RE: Announce loop-AES-v1.3b file crypto package
From:       "IT3 Stuart B. Tener, USNR-R" <stuart () bh90210 ! net>
Date:       2001-07-11 22:10:00
[Download RAW message or body]

Miket:

	It really made no sense to me to here you say that having as many bits as
you want is not a safe thing to do as juxtaposed against a backdrop of
security for purposes of a threat of law enforcement investigation,
intrusive subpoena or just playing with crypto. I presume you meant that
there must be a minimum number of bits to have. I personally am not breaking
the law, nor am I worried about being served with any intrusive subpoena,
but I do believe in having a level of encryption able to be stronger than
what would be subvertable by average law enforcement only as a bar to
measure up against how strong my encryption methodology and implementation
is.

	Are you saying that the implementations of crypto this group is using are
not strong enough to subvert even law enforcement? I would tend to disagree
with that, since the NSA is using AES! I think you had better think again
about what you just said, I doubt anyone will take those words too
seriously.

	I think that without having to learn a great deal about the rules of
entropy weighting, and such, a nice thing to do would be to determine (I
think Peter will wonder about this too), what would provide a strong and
usable encryption standard for appliance operator users? I am not so into
crypto that I care to learn all about entropy and such, I am interested in
learning some basic rules, which I can apply to using these technologies.

a) What encryption standard is strongest, and can be used to not slow my
work down to such a point that I start to dislike using the encryption at
all? I will presume that AES falls into this category
b) What rules ought we follow to generate a useful pass phrase, which will
keep us secure? I do not intend to write it down, I will learn it, no matter
how difficult, because it is important to me, and I will make a task of
memorizing the phrase, period.

I can understand the frustration Peter is experiencing, as this group spends
so much time on the most intricate details of every topic. After hearing of
all these bugs, problems, debates, and such, I am beginning to think it is
unlikely I can really implement a useful encryption standard under Linux,
and am resigned to using what W2K has built in. But, all I know is I am
scared to use the I-patch cause it seems to have bugs I don't understand
clearly (the "IV" bug), Crypto API is perhaps in a development stage right
now, and so may or may not be debugged at this point (hmm, do we trust our
valuable data to such software?) and the loop-aes driver (if we use it), I
am not sure how to choose a pass phrase which will render it protective, and
not hackable cause I used a bad pass phrase, that is where I am.

	Now I do wish to participate in the development of the Crypto API such that
it can support hardware I may choose to use (an "e-token" which will soon
have Linux drivers that work and such).

	What do you advise?


Very Respectfully,

Stuart Blake Tener, IT3, USNR-R, N3GWG
Beverly Hills, California
VTU 1904G (Volunteer Training Unit)
stuart@bh90210.net
west coast: (310)-358-0202 P.O. Box 16043, Beverly Hills, CA 90209-2043
east coast: (215)-338-6005 P.O. Box 45859, Philadelphia, PA 19149-5859

Telecopier: (419)-715-6073 fax to email gateway via www.efax.com (it's
free!)

JOIN THE US NAVY RESERVE, SERVE YOUR COUNTRY, AND BENEFIT FROM IT ALL.

Wednesday, July 11, 2001 2:53 PM

-----Original Message-----
From: owner-linux-crypto@nl.linux.org
[mailto:owner-linux-crypto@nl.linux.org]On Behalf Of Mike Touloumtzis
Sent: Wednesday, July 11, 2001 2:42 PM
To: linux-crypto@nl.linux.org
Subject: Re: Announce loop-AES-v1.3b file crypto package

On Sun, Jul 08, 2001 at 01:37:39AM -0700, IT3 Stuart B. Tener, USNR-R wrote:
> Ms. Harris, et al.:
>
> Given such a methodology as described below: we start at 90bits of
> entropy, where do we end of if we fully implement this strategy?

You can have as many bits as you want if you're willing to use a
long enough passphrase.  At a certain point you'll have to start
writing them down, though.  This is probably OK if you're the average
forgetful Joe and the risk of irrevocably losing your data outweighs
the risk of someone violating the physical security of your home,
office safe deposit box, etc. order to get the passphrase.

It's not a good idea if you're a hard-core cypherpunk, are at risk
of law enforcement investigation or intrusive subpoena, or are just
playing with crypto because it's fun and don't have any important
data under encryption :-).

> As well, where do we end up if we create 5 pass phrases using the
> rules below, and each week we rotate from one of the five pass phrases?
> Exactly where do we end up?

Each passphrase is independent of all others, and should be secure.
Choosing how often to rotate passphrases is something else entirely;
it depends on your assessment of risk of compromise as a function
of time, severity of compromise, and risk associated with passphrase
changes.  I can't really comment on that.

>
>         I am thinking of writing a piece of software (in C) to generate
such
> passwords, has anyone thought about doing this? To do it I would need to
> draw an exact set of rules for the software to follow, can we narrow it
down
> a bit, so that I can do this?

A program that implements the algorithm I described is attached.
It would be cool if folks on the list would check it over for
correctness.  This implementation loads the whole dictionary into
memory so be careful with those really huge dictionaries :-).

miket


Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

[prev in list] [next in list] [prev in thread] [next in thread]