Cryptography-Digest Digest #743
Cryptography-Digest Digest #743, Volume #12 Fri, 22 Sep 00 08:13:00 EDT Contents: Cryptography FAQ (08/10: Technical Miscellany) ([EMAIL PROTECTED]) Cryptography FAQ (09/10: Other Miscellany) ([EMAIL PROTECTED]) Crossposted-To: talk.politics.crypto,sci.answers,news.answers,talk.answers Subject: Cryptography FAQ (08/10: Technical Miscellany) From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: 22 Sep 2000 11:20:33 GMT Archive-name: cryptography-faq/part08 Last-modified: 94/01/25 This is the eighth of ten parts of the sci.crypt FAQ. The parts are mostly independent, but you should read the first part before the rest. We don't have the time to send out missing parts by mail, so don't ask. Notes such as ``[KAH67]'' refer to the reference list in the last part. The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography FAQ is posted to the newsgroups sci.crypt, talk.politics.crypto, sci.answers, and news.answers every 21 days. Contents 8.1. How do I recover from lost passwords in WordPerfect? 8.2. How do I break a Vigenere (repeated-key) cipher? 8.3. How do I send encrypted mail under UNIX? [PGP, RIPEM, PEM, ...] 8.4. Is the UNIX crypt command secure? 8.5. How do I use compression with encryption? 8.6. Is there an unbreakable cipher? 8.7. What does ``random'' mean in cryptography? 8.8. What is the unicity point (a.k.a. unicity distance)? 8.9. What is key management and why is it important? 8.10. Can I use pseudo-random or chaotic numbers as a key stream? 8.11. What is the correct frequency list for English letters? 8.12. What is the Enigma? 8.13. How do I shuffle cards? 8.14. Can I foil S/W pirates by encrypting my CD-ROM? 8.15. Can you do automatic cryptanalysis of simple ciphers? 8.16. What is the coding system used by VCR+? 8.1. How do I recover from lost passwords in WordPerfect? WordPerfect encryption has been shown to be very easy to break. The method uses XOR with two repeating key streams: a typed password and a byte-wide counter initialized to 1+the password length. Full descriptions are given in Bennett [BEN87] and Bergen and Caelli [BER91]. Chris Galas writes: ``Someone awhile back was looking for a way to decrypt WordPerfect document files and I think I have a solution. There is a software company named: Accessdata (87 East 600 South, Orem, UT 84058), 1-800-658-5199 that has a software package that will decrypt any WordPerfect, Lotus 1-2-3, Quatro-Pro, MS Excel and Paradox files. The cost of the package is $185. Steep prices, but if you think your pw key is less than 10 characters, (or 10 char) give them a call and ask for the free demo disk. The demo disk will decrypt files that have a 10 char or less pw key.'' Bruce Schneier says the phone number for AccessData is 801-224-6970. 8.2. How do I break a Vigenere (repeated-key) cipher? A repeated-key cipher, where the ciphertext is something like the plaintext xor KEYKEYKEYKEY (and so on), is called a Vigenere cipher. If the key is not too long and the plaintext is in English, do the following: 1. Discover the length of the key by counting coincidences. (See Gaines [GAI44], Sinkov [SIN66].) Trying each displacement of the ciphertext against itself, count those bytes which are equal. If the two ciphertext portions have used the same key, something over 6% of the bytes will be equal. If they have used different keys, then less than 0.4% will be equal (assuming random 8-bit bytes of key covering normal ASCII text). The smallest displacement which indicates an equal key is the length of the repeated key. 2. Shift the text by that length and XOR it with itself. This removes the key and leaves you with text XORed with itself. Since English has about 1 bit of real information per byte, 2 streams of text XORed together has 2 bits of info per 8-bit byte, providing plenty of redundancy for choosing a unique decryption. (And in fact one stream of text XORed with itself has just 1 bit per byte.) If the key is short, it might be even easier to treat this as a standard polyalphabetic substitution. All the old cryptanalysis texts show how to break those. It's possible with those methods, in the hands of an expert, if there's only ten times as much text as key. See, for example, Gaines [GAI44], Sinkov [SIN66]. 8.3. How do I send encrypted mail under UNIX? [PGP, RIPEM, PEM, ...] Here's one popular method, using the des command: cat file | compress | des private_key | uuencode | mail Meanwhile, there is a de jure Internet standard in the works called PEM (Privacy Enhanced Mail). It is described in RFCs 1421 through 1424. To join the PEM mailing list, contact [EMAIL PROTECTED] There is a beta version of PEM being tested at the time of this writing. There are also two
Cryptography-Digest Digest #743
Cryptography-Digest Digest #743, Volume #10 Wed, 15 Dec 99 07:13:01 EST
Contents:
Re: NAI granted export license for PGP ([EMAIL PROTECTED])
Re: Simple newbie crypto algorithmn (Steven Siew)
Re: How easy would this encryption be to crack? - revised (Steven Siew)
Re: Why no 3des for AES candidacy ("Douglas A. Gwyn")
Re: Why no 3des for AES candidacy ("Douglas A. Gwyn")
Re: Deciphering without knowing the algorithm? ("Douglas A. Gwyn")
Re: security of 3des ?= des ("Douglas A. Gwyn")
Re: Simple newbie crypto algorithmn ("Douglas A. Gwyn")
Re: Deciphering without knowing the algorithm? (Guy Macon)
Re: The Code Book (Guy Macon)
Re: Simple newbie crypto algorithmn ([EMAIL PROTECTED])
Re: Why no 3des for AES candidacy ("Tim Wood")
Re: Why no 3des for AES candidacy ("Tim Wood")
Re: Why no 3des for AES candidacy ("Tim Wood")
Re: Simple newbie crypto algorithmn (Steven Siew)
Re: Simple newbie crypto algorithmn (Steven Siew)
Re: Deciphering without knowing the algorithm? (CLSV)
Re: Simple newbie crypto algorithmn (CLSV)
Re: Simple newbie crypto algorithmn (CLSV)
From: [EMAIL PROTECTED]
Subject: Re: NAI granted export license for PGP
Date: Wed, 15 Dec 1999 05:27:36 GMT
Mike Andrews [EMAIL PROTECTED] wrote:
: Why haven't we seen any people ranting about "NSA must have solved the
: discrete log and factoring problems" yet? :)
They've all been taken away in the black helicopters.
Don't be silly, the NSA uses standard rental car models and colors for
this sort of thing, not an eye-catching black helicoptor. They've all
been taken away in white Plymouth Voyagers. :)
--
Matthew Gauthier [EMAIL PROTECTED]
--
From: Steven Siew [EMAIL PROTECTED]
Subject: Re: Simple newbie crypto algorithmn
Date: Wed, 15 Dec 1999 16:46:44 +1100
David Wagner wrote:
In article [EMAIL PROTECTED],
Steven Siew [EMAIL PROTECTED] wrote:
It's not designed to be fast. It's designed to be secure. Again memory
was not considered by me during the design process.
Anyone can design a secure cipher if it's allowed to be big and slow.
Just use umpteen-DES, or somesuch, with ten copies of D. Scott's favorite
chaining mode thrown in for good measure (why not?).
The question is, why would anyone use a new, slow algorithm when there
are others available that are both faster and better understood (= more
likely to be secure)?
(Maybe this was intended only for fun, and was not suggested for actual
use. If so, I apologize; my comments would be irrelevant in such a case.)
Why would anyone uses a new slow algorithmn? People would use it if they
can TRUST it! Please refer to my design criteria.
So I set about proving the above statement. In short I want to
write a crypto program with the following chracteristics:
1. The program must be simple and easy to understand. Thus
the public can see easily the strengths of the encryption.
2. The program must be cryptographically powerful enough not to
be cracked even by using all the computers in the world in
less than a 1000 years.
3. No special knowledge of arcane cryptography is required.
No maths more difficult than that encountered in high
school is required.
Remember I'm aiming at people who is not particularly skilled in
cryptography. People are naturally reluctant to use program which they
don't understand how it works.
Steven Siew
--
From: Steven Siew [EMAIL PROTECTED]
Subject: Re: How easy would this encryption be to crack? - revised
Date: Wed, 15 Dec 1999 17:05:27 +1100
Christoffer Lernö wrote:
Oops.. saw the flaws myself.
What about this:
(the class itself holds the two key arrays (byte[]) meKeyA and meKeyB,
there are also
two looking variables, meSpin (getting its starting value from meKeyA
meKeyB)
and meSpin2 with starting value 0)
To decode a byte b:
Can you tell us why you think this is a strong crypto algo? Frankly I'm
not good at java, is byte same as char or is it same as unsigned char?
Kindly provide some explaination to your algo. What are your design
criterias? Have you thought about how to crack it yourself? How well
does it defend against known plaintext attacks?
How well does it encrypt a plaintext which differs from another
plaintext by a single bit?
Steven Siew
--
From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject: Re: Why no 3des for AES candidacy
Date: Wed, 15 Dec 1999 06:48:49 GMT
albert wrote:
Get a clue, watch some conspiracy movies or something.
That's apparently where you get *your* "information".
Mine is much more reliable.
--
From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject
Cryptography-Digest Digest #743
Cryptography-Digest Digest #743, Volume #9 Mon, 21 Jun 99 07:13:03 EDT
Contents:
Re: A Thought or a Quoater ("rosi")
Re: 1024 bits encryption for web based e-mail (hushmail) (Fred)
Re: HushMail -- Free Secure Email (a little long) (Fred)
Re: RC4 Susectability ([EMAIL PROTECTED])
Re: Cipher ([EMAIL PROTECTED])
Re: Where can i get the code from Bruce Schniere's applied crytptography?
([EMAIL PROTECTED])
Re: Where can i get the code from Bruce Schniere's applied crytptography? ("Sven
Knispel")
Re: IDEA in "aplied cryptography" BRUCE SCHNEIER (kurt wismer)
Re: Good book for beginning Cryptographers? ("GyungHwa Jun")
Re: Good book for beginning Cryptographers? (Jim Gillogly)
Re: alt.security.scramdisk ("Andy Jeffries")
Re: Security ... or just lies (wtshaw)
Re: *** FAKE KEYS AGAIN *** ("Sam Simpson")
From: "rosi" [EMAIL PROTECTED]
Subject: Re: A Thought or a Quoater
Date: Sun, 20 Jun 1999 23:25:00 -0400
Key Establishment
(Certain things, for succinctness, are implicit. If you are not clear,
it almost surely is because I did not make things clear. Apologies in
advance)
NS (Needham-Schroeder) may be the 'basic' construct of almost all key
establishment protocols (including hybrid ones) using public-keying. Here
freshness of session keys is facilitated through a primitive that offers
the inseparable (mutual) identification of the communicating parties and
the establishment of a _SHARED_ key (which is of course overwhelmingly of
a symmetric keying scheme). Besides the neatness of the primitive, the key
established is not biases toward either party, as both can be guaranteed
to constibute equally.
The attackers are faced with two problems. Breaking the protection by
the public-key method or breaking the symmetric one, both are independent
of each other and the weakest defines the real security. (The former via
obtaining the decryption key is more beneficial for sure).
Two (public) keys are involved in NS. However, the strength is not
the 'sum' of the two (e.g. two 1024-bit RSA combined give 2048-bit RSA
strength, and the security assumption is assumed here). Instead, it
gives at 'best' 1025-bit strength. Yet ideally we would like the 2048-
bit strength.
More sophisticated schemes employ an (essentially) two-key approach
where one of the public-keying 'component' is signing. However, It
requires the maintenace of two public keys, both static. Ideally, we
would like to just keep one static.
Even though the above described two-public-key method takes 'advantage'
of signing, non-repudiation is never an issue in such a primitive in
general, yet verification is a 'public' operation rather than a private
one. Therefore in essence, only one public-keying is really utilized to
the full extend. In addition, in situations (which are very common) where
the two sides have unbalanced security, the failure of 'one side' can
render the complete communications between the 'failing side' and any
other party totally exposed. An ideal situation is to prevent this, i.e.
passive attacks will still not succeed even when one of the public keys
is completely broken.
It seems a rule rather than an exception that whenever two public keys
are involved, the security depends on one rather than 'both'. In addition,
the dependency on a third trusted party adds 'unecessary convolution'.
While special applications may be improved in efficiency, c.f. Beller-
Yacobi, the intensive computation for public-keying operations remains a
nuisance. The burden on the 'server' side, for example, can hardly be
alleviated (as of now).
Taking our general assumption and the optimistic 'view on life', we
behave as if, for example, the 'cycles' can never be found efficiently.
This is highly necessary. I can not imagine one wearing a straight face
when he believes that is not the case. Under that assumption, the worst
catastrophe is something like: 2^100 times faster now for that special
kind. Something suddenly brought within reach that was previously thought
otherwise. The impact of such an event is of course closely related to
our definition of 'secure', 'broken', etc., a too hard topic I do not
want to go in, knowing that more answers can be received than expected
but no 'solution'. Similarly, if the issue is broadened, we will never
see an end of it. In particular, the 'initial key establishment' is not
touched here.
One layer may not be a too good idea. But this is a mere personal
taste. 'Why two layers? Why not just more bits but keep one layer? etc.'
A judgement call.
Next, the weird thing --- key secure. See you next time.
Thank you very much.
--- (My Signature)
--
From: Fred [EMAIL PROTECTED]
Subject: Re: 1024 bits encryption for web based e-mail (hushmail)
Date: Mon, 21 Jun 1999 03:04:39
