Cryptography-Digest Digest #827, Volume #8 Sun, 3 Jan 99 01:13:03 EST
Contents:
Re: On leaving the 56-bit key length limitation ([EMAIL PROTECTED])
Re: Q: Key length: how is optimal length determined? (DJohn37050)
Re: RSA-NULL security&Back Door ([EMAIL PROTECTED])
Re: ZIP encryption safe? (Mark Andreas)
TinyIDEA update (Mark Andreas)
CRC Press Cryptology Books Increase in Price (CryptoBook)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: On leaving the 56-bit key length limitation
Date: Sun, 03 Jan 1999 02:05:42 GMT
In article <[EMAIL PROTECTED]>,
Bryan Olson <[EMAIL PROTECTED]> wrote:
>
> Well, Ed asked for comments. Mine happen not to be
> favorable. Sorry if the tone seems to be "everything
> Ed says is wrong".
>
Here is my rejoinder.
> Ed Gerck wrote:
> > 1. First, I wish to point out that Theoretically-Secure Cryptographic
> > Systems (hereafter TSCS) do not depend on key-length for secrecy --
> > in their design region. In fact, Shannon already showed 50 years ago
> > that a TSCS does not depend on key-length when one works within the
> > system's "unicity distance".
>
> Staying within the unicity distance only ensures that
> more than one possible decryption exists. A cryptanalyst
> may still get large amounts of useful information.
No, you are mistaken -- if you mean the plaintext (but, what else would you
mean?). Where did you get this strange notion of unicity? You then reinforce
my opinion that unicity needs to be revisited, understood in a broader scope
and revaluated as a pratical tool.
>
> > So, the factor we need to work on in
> > order to protect our privacy is "unicity distance" -- not key length.
>
> No, that doesn't follow.
Yes, it does. See above. My point is that key length only weakly determines
the security of any system -- while unicity strongly defines it. Very large
key length systems can be naively broken and very short key length systems
may never be broken (never is never) -- all as a function of unicity.
>
> > 3. It is interesting to note that a TSCS cannot be attacked by
> > exaustive key-search -- denying thus the very "brute-force attack"
> > that looms over protocols under key length limitations. So, I can
> > even safely use 56-bit DES (notwithstanding fast and cheap hardware
> > key-searching devices) within a TSCS's design region.
>
> If TSCS is defined only as denying the attacker ciphertext
> that covers the unicity distance, then the claim is false.
TSCS is defined as a system which works within the "unicity distance" --
please use it AS defined if you want to draw conclusions...
> Exhaustive search may yield only a few possible plaintexts.
> If I can narrow the message down to "Attack at dawn with
> 3000 men" or "Attack at dawn with 3006 men", then I've
> obtained almost all the useful intelligence.
>
No, you cannot decipher anything meaningful -- you are confusing unicity with
something else.
> [...]
> > For
> > example, would a user feel limited if I say 56 Kbyte messages are
> > allowed for each 56-bit session key -- with theoretically unbreakable
> > security?
>
> Our user might not feel limited by what you say there, but
> that would change after she reads the fine print. To achieve
> what Ed suggests, he _must_ impose other restriction.
How do you know? Is this a guess? Why do you say "must"?
> Can the user send any 56KB message she wants?
Yes.
>Is she limited to environments in which she has a second secure channel?
No, except for the first key (of course).
>
> > 6. The final word on cryptographic strength is thus not to be found
> > in enforced export controls for key length. It is to be found in our
> > own drawing boards in terms of a system's "unicity distance" and its
> > derived design issues, which is feasible to deal with and lies in our
> > hands.
>
> Yuck, manager-speak.
You may recognize, perhaps as an introduction to the concept of "unicity
distance" as it is, that your phrase above is akin to a ciphertext for which I
cannot decode any intelligible meaning -- hence, without any cipher you have
just exemplified a TSCS system '-)
>
> > 7. To reach the heart of the matter, one must devise ways to thwart
> > automatic surveillance decoding -- which is additional from only
> > making it harder or theoretically-impossible to decipher the
> > messages, as dealt with by TSCSs. The objective here is to make
> > decryption either ambiguous or ambiguously related to the key, even
> > if sucessful (say, by collusion, forced escrow, etc.). So, the
> > attacker would have difficulties to detect that a key does NOT work,
> > that it DOES work, and what the decrypted message is, from a possible
> > list of choices. To contrast, in DES, a given key either produces
> > garbage or readable text -- too easy for an attacker. One simple
> > suggestion is to reverse one or two random bits in each encrypted
> > block of a TSCS (in a block's "salt window" defined for example by
> > the key itself) so that automatic decoders would have to be much
> > augmented to cover the enlarged search space and search time would
> > also increase for every tried key (the user would do all that rather
> > quickly, since he has the right key).
>
> Wouldn't the complexity of the user's system, and his
> decryption time increase by at least as great a factor
> as the attackers?
Not in the cases mentioned, since the user KNOWS the key.
> What user wants nondeterministic decryption?
Pls read again, it is not nondeterministic to the user -- it is to the
attacker.
>How is this form of additional complexity better than slow key setup.
>
With my comment above, pls see that the attacker would not be able to decide
what is the right message or, what is wrong.
Note that this is EASY with DES, as I remarked. Too easy.
> > Another suggestion is to
> > develop TSCSs that can provide ambiguous and meaningful decryptions
> > -- which the user's system can choose based on some trusted
> > information provided out-of-band.
>
> Is the out-of-band channel private?
The out-of-band channel is (for example) simply the previous msg, within
unicity. It is out-of-band because it is an event in the past.
>If so, why not use
> it and forget the TSCS?
I hope it is clearer from above.
>How do we get this private
> channel assuming the key-length restrictions?
As above. You may also get it as a phone call -- which WA does NOT prohibit --
and which may influence the settings on some check boxes.
>If it's not
> private, why wouldn't the attacker use it to distinguish
> the correct message?
>
As above, it is private. Either directly in the protocol or ex-protocol.
> > To close, in order to extract the full benefit from such approach to
> > security as commented in the seven items above, I believe that one
> > must first revisit the concept of "unicity distance" -- since it is
> > usually regarded more as a "proof-of-concept" definition than a
> > practical tool.
>
> Be careful. If the current understanding of unicity
> distance fails to imply that the envisioned systems are
> secure, that might well be a point in its favor.
>
I cannot decipher your text -- I guess you have another unicity example :-)
But, in case you could not decipher mine ;-) ... let me "re-key" it:
The current concept of "unicity distance" leads to wrong results and it is not
practical. For example, Bruce Schneier (and others) say that the unicity
distance of DES is 16 bytes of English, some say 20 bytes. However, it is not
so. It is at most 4 bytes of English -- perhaps as low as 1 byte for some
systems.
Cheers,
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Q: Key length: how is optimal length determined?
Date: 3 Jan 1999 03:25:44 GMT
The AES requires 128, 192 and 256 bit keys to be supported for all candidates.
ANSI X9F1 requires a minimum keysize of 1024 bits for RSA and DSA/DH and 161
bits for elliptic curve.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RSA-NULL security&Back Door
Date: Mon, 28 Dec 1998 11:24:17 GMT
Hello Frank,
Thank you for very interesting algorithm.
There is only not important misleading in
it’s description.
Let t be a biggest index for which e[t] is
not equal NULL.
Then binaries representation of e looks as:
e[0]+2*e[1]+4*e[2]+...+2^t*e[t]
Then your FOR loop must be corrected to:
for (i=t; i>=0; i--) {
I would like to insert this algorithm in to
my Web.
Best regards and Happy New Year!
Sincerely yours
Alex
In article <[EMAIL PROTECTED]>,
Frank Paehlke <[EMAIL PROTECTED]> wrote:
> Hello Alex,
>
> > 2. I do not believe that in such implementation is calculated
> > really an exponent m^e mod n . There is no computer
> > architecture which can keep such numbers during normal
> > RSA encryption process with a big enough key.
>
> you don't need to compute m^e in order to get m^e mod n, which would
> indeed be quite impractical if m, n, and e were sufficiently large.
> The modular exponentiation can be done much more efficienty using a
> "square and multiply" algorithm:
>
> Let the binary representation of e be e =
> e[0]+2*e[1]+4*e[2]+...+2^n*e[n].
> Then m^e mod n can be calculated as follows (in pseudo C syntax):
>
> res=1;
> for (i=n; i>=0; i--) {
> res = (res*res) mod n;
> if (e[i] == 1) res = (res*m) mod n;
> }
> /* now, res==m^e mod m */
>
> There are, of course, speedups to this simple scheme, but I just wanted
> to point out the basic principle.
>
> Hope that helps,
> Frank
>
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Mark Andreas <[EMAIL PROTECTED]>
Subject: Re: ZIP encryption safe?
Date: Sat, 02 Jan 1999 21:38:31 -0600
http://come.to/Delphi-Box wrote:
>
> Hello,
>
> sorry for asking a question which might have been asked already 100s
> of times before, but I'm not too familiar with crypto topics and just
> asked me the following:
>
> since I've read that especially using long ZIP passwords (15 chars and
> more, including non-alphanumeric chars) takes enourmously long to
> decrypt and just brute-force decryption helps.
>
> How safe is that, compared to, let's say, 128bit Blowfish encryption ?
> I just want to get a feeling, I don't need exact factors.
>
> Thanks for your help,
> Richey
Even if the pkzip cipher were secure, it uses your password to
initialize 3 32-bit encryption variables, so at best it would have 96
bits of security. If the pkzip cipher were secure, one wonders why it
got export approval, while Blowfish can't get export approval if it has
more than a 32-bit key, or DES or RC4 can't get approval having more
than a 40-bit key.
The above is ignoring the new key-recovery limit of 56-bits, which
wasn't in effect when the pkzip cipher was released
--
=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/
Mark Andreas <[EMAIL PROTECTED]> http://www.sky.net/~voyageur
PGP key 77EF76B1 available via key server, finger or webpage
=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\
------------------------------
From: Mark Andreas <[EMAIL PROTECTED]>
Subject: TinyIDEA update
Date: Sat, 02 Jan 1999 21:47:49 -0600
=====BEGIN PGP SIGNED MESSAGE=====
Announce: New version of TinyIDEA
This is announcing the release of an upgrade to TinyIDEA. TinyIDEA,
currently available in idea3a.zip, is a very small DOS program which
performs 128-bit IDEA in CFB feedback mode - after hashing a keyboard
passphrase using Tandem Davies-Meyer. TinyIDEA encrypts the file
in-place, meaning there is no need to secure-wipe the plaintext after
encryption, and there is no risk of out-of-diskspace errors.
I have continued size optimizations on this program, and have
released the upgrade. The new version can be downloaded at:
http://www.sky.net/~voyageur/tinyidea.htm
Unfortunately, my program must be export restricted. The predecessor
version can be downloaded from Fauzan Mirza's page:
http://www.cs.rhbnc.ac.uk/~fauzan/tinyidea.html
The upgraded program does have a few extras, including:
* Smaller size. The current idea3a.com is 503 bytes. The upgrade
contains a program 100% compatible with idea3a.com, with a size
of only 366 bytes.
* Assembler source code is switched from TASM over to A86, which
can be downloaded at http://www.eji.com
* Passphrase can be put on the command line.
* Includes several varations, with different combinations of
features. These features may introduce incompatibility with
idea3a.com, but were introduced in an attempt to improve
security.
* More
The most important change in the new version of TinyIDEA is getting
rid of the initialization of the feed back with all 0x00's.
Previously, if you always used the same passphrase, this caused all
files with similar beginnings to have similar beginnings to their
ciphertext. You could XOR both first-blocks together and get the
same result as if you XOR'ed both first-block plaintexts together.
However, once any bit difference occurs, no such relationship exists
for later blocks.
Encryption-in-place without changing the filesize is one crucial
element in keeping the program's filesize small. The encryption
subroutine is actually a very small part of the program. A good
portion of the program is involved with file-handling and hashing the
text passphrase down to a 128-bit value.
For the encryption key to change while using the same text
passphrase, I had to use information about the file which would be
available to the person decrypting the file. This means using the
filesize and filename as part of the process which generates the
encryption key.
For the main upgrade version, I am only combining the filesize with
the passphrase. TinyIDEA uses older Interrupt function-calls, which
means those who are using Windows 95 may try to encrypt
LongFilename.TXT, with TinyIDEA seeing LONGFI~1.TXT. Unfortunately,
at time of decryption, the shortname isn'g guaranteed to be the same,
and could be LONGFI~2.TXT, or something else.
The main TI.COM will combine the filesize with the passphrase, and an
additional TISN.COM will combine the filesize and the filename with
your text passphrase.
Combining the filesize will greatly reduce the odds that 2 messages
will have the same encryption key, and using TISN.COM would further
reduce the odds - especially if your practice is to always use
different filenames for each message.
Double encryption with the same passphrase will still result in
decrypting the first block. Even though the initialization will no
longer be 0x00's, you will be encrypting the same block twice, and
the feedbacks will cancel each other out. However, you shouldn't be
doing double-encryption, but rather encrypt/decrypt/encrypt, with 2
or 3 different keys.
If you need to email me, my RSA-2048 key is:
- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQENAzFbXkoAAAEIAJkM0XM00Kobwpq2QdiIxe1kpj54zB7LKQTM7ZtXgldluiKR
uwSLKaGqE1TApj4xVHxI3HolxFlIWhIRHf2bZe7dUf3m7hT83d4UmzuEZ3OYETek
kpBcc0n71vkBbbITUlHivBj/2Eg6HO5cRvoO8UmOibJbKn31uZyf/Cuiwr/yYGVA
b42QmOlXVAY6spFjv3KkpqHEz75bxNEjIv4FFq5AsvIOgmHtdqpzG6R5qwIldO5d
dqrz+6yjPfBBYw0NZMFObWU/DYWrQe7W/jumMgsUTiE7H06jC6clD7TN6NaIY44d
6hBneGfIf2LKQHLPr5iR/8sLoAnax0tkWnfvdrEABRG0H01hcmsgQW5kcmVhcyA8
dm95YWdldXJAc2t5Lm5ldD6JARUDBRAxYFTKx0tkWnfvdrEBAWDhB/wLI71EGTcz
vjjqliFrnVXUV443hCioX7n6X8pHPYEpfeB8Ux6J4p9irj85C8Mlep2pFlHGkP6A
gQXjkHD7x9h8uTL9+/VQ1m88lXCSUML+SKM5A/EPWt+h40gjp5SEVTPVplU+MLi0
vTCHWMGyrFwShVabYe4Ar5JGGSo1tBIBgxp1nack/f3YB9xrS0y8MSz+rsARPIq7
p88te2Gjt9kMcwtOJwC9DDkwBA5SHO4FBapjJvJ0iaHzSw33K2b9DcN2QZc6LfDa
GDcgtYDR7NqM+nRGR8EVuorFNtigVMlFTI2qLE6+bQAUQAHl13Fs7bSvkvjcN+GD
6sUD//nFad1I
=qoJc
- -----END PGP PUBLIC KEY BLOCK-----
=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/
Mark Andreas <[EMAIL PROTECTED]> http://www.sky.net/~voyageur
PGP key 77EF76B1 available via key server, finger or webpage
=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\
=====BEGIN PGP SIGNATURE=====
Version: 2.6.2
Comment: 2048-bit RSA key at: http://www.sky.net/~voyageur/crypto.htm
iQEVAwUBNo7ku8dLZFp373axAQFzLQf/Yn+wam1RYm34qoGV+pSaas7ET5s2YjDZ
dlS3cPgv6yLzW2dohcH1T5GwQebnK2JI/X8WAkshiAWhdX0CSh9uWztEMlBtyb6A
VglR3YIqxVAVc9tTZzD9qPgXpuxbzs3mD6iQ+evwtkX11mRFZY71yrtInn5PDd55
MCtFW9ikinqVbtQ1RLLWnAaDfCh8dCqUFOyL1pYFXOAiMdeF9ETk/n8ozQyf7wsA
gj4oqJR9fw5hBrHywoNbqVEf9qj8ptjXgMeYqtz78BPJteqaHfyUTSkUytSoIfaV
/+H//V/qbUmGxsU7ZT4dOsi496rqve5TLSwUfHTOsIkEsG4/vR63WA==
=vFYq
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (CryptoBook)
Subject: CRC Press Cryptology Books Increase in Price
Date: 03 Jan 1999 05:32:20 GMT
CRC Press, the publisher of several important books on cryptology (see listings
below), has announced higher prices for 1999. This is your last chance to order
these books, or any CRC Press Book currently in print, at the lower 1998
prices. Complete orders must be received by CCB by 12 January 1999 to qualify
for the 1998 prices. Please inquire about books not listed.
Handbook of Applied Cryptography
by A. Menezes, P. van Oorschot, and S. Vanstone
"This book is intended as a reference for professional cryptographers,
presenting the techniques and algorithms of greatest interest to the current
practitioner, along with the supporting motivation and background material. It
also provides a comprehensive source from which to learn cryptography, serving
both students and instructors. In addition, the rigorous treatment, breadth,
and extensive bibliographic material should make it an important reference for
research professionals. Our goal was to assimilate the existing cryptographic
knowledge of industrial interest into one consistent, self-contained volume
accessible to engineers in practice, to computer scientists and mathematicians
in academia, and to motivated non-specialists with a strong desire to learn
cryptography." - From the preface. For a review, see Cryptologia, Apr97. CRC
Press, 1997, xxviii + 780 pp, Hardbound.
1999: Pub. $94.95, Member $84.95, Non-member $87.95
1998: Pub. $87.00, Member $76.95, Non-member $79.95
Cryptography: Theory and Practice
by Douglas R. Stinson
"My objective in writing this book was to produce a general, comprehensive
textbook that treats all the essential core areas of cryptography ... I am
aware that cryptography courses are offered at both the undergraduate and
graduate levels in mathematics, computer science, and electrical engineering
departments. Thus, I tried to design the book to be flexible enough to be
useful in a wide variety of approaches to the subject." - From the Preface.
Chapter 1, Classical Cryptography, discusses the cryptanalysis of Affine,
Substitution, Vigenere, Hill, and LFSR-based stream ciphers. Other chapters
include: Shannon's Theory, The Data Encryption Standard, The RSA System and
Factoring, Other Public-key Cryptosystems, Signature Schemes, Hash Functions,
Key Distribution and Key Agreement, Identification Schemes, Authentication
Codes, Secret Sharing Schemes, Pseudo-random Number Generation, and
Zero-Knowledge Proofs. CRC Press, 1995, xiv + 434 pp, Hardbound.
1999: Pub. $89.95, Member: $79.95, Non-member $82.95
1998: Pub. $79.95, Member: $69.95, Non-member $72.95
Computer System and Network Security
by Gregory B. White, Eric A. Fisch, and Udo W. Pooch
The authors' objective was to produce a book equally suitable for use as a text
in a college course on computer security and as a reference book for computer
security professionals. The contents are: Fundamentals of Computer Security,
Risk Analysis, Developing Secure Computer Systems, Security Models, User
Authentication, Access and Information Flow Controls, Auditing and Intrusion
Detection, Damage Control and Assessment, Network Security, Firewalls, Database
Security, Cryptography, Malicious Code, Government-Based Security Standards,
Case Studies, and Information Warfare. CRC Press, 1996, xii + 296 pp,
Hardbound.
1999: Pub. $84.95, Member $74.95, Non-member $77.95
1998: Pub. $74.95, Member $64.95, Non-member $67.95
PRICE NOTE: Member prices are available to members of the American Cryptogram
Association, the US Naval Cryptologic Veterans Association, and full time
students.
A shipping and handling charge applies to each order. Visa and MasterCard are
accepted. For complete ordering information, a free catalog of crypto books
stocked, or for information about membership in the American Cryptogram
Association, please send email to [EMAIL PROTECTED]
Best Wishes for 1999!
Gary Rasmussen
Classical Crypto Books
E-Mail: [EMAIL PROTECTED]
Fax: (603) 432-4898
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
