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@xxxxxxxxxxx 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@xxxxxxxxxxxx [mailto:owner-linux-crypto@xxxxxxxxxxxx]On Behalf Of Mike Touloumtzis Sent: Wednesday, July 11, 2001 2:42 PM To: linux-crypto@xxxxxxxxxxxx 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/
