Cryptography-Digest Digest #456, Volume #10 Wed, 27 Oct 99 13:13:03 EDT
Contents:
Re: simple question (Jerry Coffin)
Re: do you consider this secure ? ("Roger Schlafly")
Re: Zimmerman Telegram Question (Mok-Kong Shen)
RSA Cryptography Today FAQ (1/1) ([EMAIL PROTECTED])
Re: Crypto Class to Visual C++ (test)
Re: do you consider this secure ? ("ME")
Re: Good e-mail encryption freeware? (Steve K)
Re: Unbiased One to One Compression
Re: the ACM full of Dolts? ("Tony T. Warnock")
SMARTCARD SECURITY NEWS ISSUE #7 ([EMAIL PROTECTED])
Re: This compression argument must end now (Anton Stiglic)
Re: Unbiased One to One Compression (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: simple question
Date: Tue, 26 Oct 1999 23:14:58 -0600
In article <7v5t6c$3t0o$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> I'm sure that this is very easy to most of you. The algorithm of DES is way
> more complicated than of RSA, but yet RSA is much slower (1000 times in
> hardware?) than DES, is it simply because of c = m^e mod n? If so, is there
> any method or algorithm to optimize or speed up the algorithm?
It's because (for any practical use) you're working with _quite_ large
numbers in the calculation. If it was sufficient to work with, say,
32-bit numbers, then RSA could be quite fast. When you have to do
computations on numbers that are a 1000 or so bits apiece, even
something as simple as addition becomes a relatively slow process.
> Second, is there an algorithm available to guarantee a number is prime, such
> as the large prime numbers p and q in RSA?
For most practical purposes, no. You generally use a couple of tests
that give you an extremely high probability that the number is prime,
but don't absolutely guarantee it. There _are_ tests that will truly
guarantee that numbers are really prime, but most of them are MUCH
more difficult tests to run.
There are also tests for primacy of some specific numbers (e.g.
Mersenne numbers) that give absolute answers, but you generally do NOT
want to limit yourself to the extremely small set of numbers that can
be tested like this.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: do you consider this secure ?
Date: Tue, 26 Oct 1999 21:24:33 -0700
David A Molnar <[EMAIL PROTECTED]> wrote in message
news:7v5g89$h20$[EMAIL PROTECTED]...
> Take your favorite public key cryptosystem C which satisfies some nice
> definition of security.
>
> Create a new scheme C' like this :
>
> Key generation : unchanged
> Decryption : unchanged
> Encryption : Encrypts the message the same way, but appends a string
> containing the message "Hi, I was encrypted with
> <public key encrypting message> by <your name here>!"
> to the end of each and every ciphertext. Correct
> values for both, of course. :)
>
> Is C' secure? when would you say so, and when not?
It reveals some info that might not otherwise be available. So
in that sense it is less secure. It also leaves open the possibility
that someone could intercept C' and modify it, so the recipient
may not be able to count on the validity of the info.
Usually the security models assume that the attacker knows
the sender's identity and algorithm, so some security claims
would not be affected.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Zimmerman Telegram Question
Date: Wed, 27 Oct 1999 10:03:38 +0200
John Savard wrote:
>
> We've all seen photographs of the coded version of the "Zimmerman
> Telegram".
Do you happen to have a count of bytes of the ciphertext?
Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
talk.politics.crypto,alt.security.ripem,sci.answers,talk.answers,alt.answers,news.answers
Subject: RSA Cryptography Today FAQ (1/1)
Date: 27 Oct 1999 11:19:34 GMT
Reply-To: [EMAIL PROTECTED]
Archive-name: cryptography-faq/rsa/part1
Last-modified: 1997/05/21
An old version of the RSA Labs' publication "Answers to Frequently Asked
Questions about Today's Cryptography" used to be posted here until May
1997. These postings were not sponsored or updated by RSA Labs, and
for some time we were unable to stop them. While we hope the information
in our FAQ is useful, the version that was being posted here was quite
outdated. The latest version of the FAQ is more complete and up-to-date.
Unfortunately, our FAQ is no longer available in ASCII due to its
mathematical content. Please visit our website at
http://www.rsa.com/rsalabs/ to view the new version of the FAQ with your
browser or download it in the Adobe Acrobat (.pdf) format.
RSA Labs FAQ Editor
[EMAIL PROTECTED]
------------------------------
From: test <[EMAIL PROTECTED]>
Subject: Re: Crypto Class to Visual C++
Date: Wed, 27 Oct 1999 11:40:52 +0200
Hi
on
http://www.heise.de/ct/ftp/result.xhtml?url=/ct/ftp/99/21/314/default.shtml&words=Verschl%FCsseln
you will find IDEA in c++,
sorry the side is in german.
Peter wrote:
> I am looking for class I could easily implement
> in my crypto app.
> Alghoritm dont have to be strong - most important
> thing is that it should be easy to use in code
> Thanx for help
> Peter
------------------------------
From: "ME" <[EMAIL PROTECTED]>
Subject: Re: do you consider this secure ?
Date: Wed, 27 Oct 1999 16:24:18 +1000
Waht are your criteria?
If it is data confidentiality, and the common string is not insidethe
encrypted block, then it is as good as any other.
If you want to prove something about the source or destination, then it's
useless unless you have a reliable, secure data management process over the
public and private keys at both end of the link - yours and the intended
recipeint.
Lyal
David A Molnar wrote in message <7v5g89$h20$[EMAIL PROTECTED]>...
>
>
>Take your favorite public key cryptosystem C which satisfies some nice
>definition of security.
>
>Create a new scheme C' like this :
>
> Key generation : unchanged
> Decryption : unchanged
> Encryption : Encrypts the message the same way, but appends a string
> containing the message "Hi, I was encrypted with
> <public key encrypting message> by <your name here>!"
> to the end of each and every ciphertext. Correct
> values for both, of course. :)
>
>Is C' secure? when would you say so, and when not?
>
>Thanks,
>-David Molnar
------------------------------
From: [EMAIL PROTECTED] (Steve K)
Subject: Re: Good e-mail encryption freeware?
Date: Wed, 27 Oct 1999 13:56:49 GMT
On Mon, 25 Oct 1999 13:31:57 -0800, [EMAIL PROTECTED] wrote:
<snip>
>I have been reading that abuot the NSA restrictions on %22hard%22 encryption
>in the US, and it sounds to me as if encyption software originating in the
>US may not be all that secure.
This is the subject of endless debate, most of which boils down to:
"Yes it is!"
"No it isn't!"
"You dumb FUD-monger!"
"You damned Federal agent!"
"Am not!"
"Are so!!"
The restrictions imposed on encryption by the U.S. are export
restrictions. Since Uncle knows very well that these regulations do
not prevent strong encryption from being used by the alleged targets
of the restrictions-- terrorists and the like-- the real explanation
is that they serve to slow down the implementation of strong
cryptography by the international business community, and thus, to
slow down the growth of cryptography use in all sectors.
I still think PGP is the best way to go, for e-mail encryption. Even
if the NSA has broken PGP wide open-- which I rather doubt-- there is
little cause for alarm, unless you are a military or economic threat
to the percieved "vital national interests" of the United States.
This, because sharing the contents of decrypted mail, or acting on
them, would reveal the fact that they can do it. And it is a very,
very safe bet that amateurs and the private sector have *not* broken
PGP wide open.
The particular advantages of PGP include, first and foremost, that it
is the most widely used crypto software, and thus, you stand the best
chance of being able to actually use it with the people you correspond
with. The best cryptography in the world is useless for email, if you
happen to be its only user.
Another advantage is the fact that PGP source code is available, and
has been subjected to lots of scrutiny. The algorithms used are very
widely known, and considered secure by the consensus of the civilian
cryptographic community.
And NAI, in signing PGP, is betting heavily that no one will ever find
a "back door" in any of the signed releases-- because that would
immediately destroy their credibility for all time, and could lead to
a ruinous class action lawsuit in the U.S..
The greatest known weaknesses in PGP are not the software itself, but
the environment it operates in. These weaknesses will apply to any
cryptographic system. These include the possibility that the user's
machine has been compromised with a trojan like NetBus or BO, or has
open fileshares accessable from the Internet, allowing remote users to
monitor and capture keys and pass phrases.
There is also a pretty good chance that Windows will write plaintext
and/or key material to its swap file, and the certain fact that many
users will fail to create pass phrases strong enough to resist
dictionary and brute force attacks. Again, these will be weaknesses
in just about any crypto system.
>So I was wondering what an alternative might be to something like PGP.
>Preferably of international origin. And preferably of the highest security
>available. Freeware would be best, but I am willing to pay too.
The "highest security available" comes from the user, more so than the
software, because the most practical way to break any really good
cipher is to break into the user's system and steal the keys. My
suggestions: Read up on strategies for creating strong pass phrases,
research and install an effective firewall program, and get a copy of
Swap File Overwriter or something similar.
It is also important to keep in mind that the person on the other end
of your encrypted conversation can not be trusted to prevent his or
her keys from being stolen, unless you know what they are doing to
prevent it. This weakness applies to all forms of cryptography, and
when you take it into account, the best that can be expected in most
cases is "casual" security: Which is a lot better than none at all,
unless you trust it more than you should.
Steve K
---Continuing freedom of speech brought to you by---
http://www.eff.org/ http://www.epic.org/
http://www.cdt.org/
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Unbiased One to One Compression
Date: 27 Oct 99 13:58:46 GMT
Tom St Denis ([EMAIL PROTECTED]) wrote:
: No actually you are wrong. Compression is part of the cryptosystem not
: the cipher or use of the cipher. This is sci.crypt not alt.security.
: You get with it.
: If you have metrics by which you can say 'this compression' makes 'this
: system' more secure then by all means share it. No more speculation
: please.
While I must confess to an emotional reaction to being told that I seem
unable to understand the intellectual accomplishments of the great David
A. Scott, still I must point out that there is some unfairness in this
criticism.
"Why Cryptography Is Harder Than It Looks" was not off-topic for this
group. Posts can discuss how to write an encryption program so that it
does not leave sensitive data in the swap file. Compressing data before
encrypting it does directly relate to the security of the resulting
messages.
Why?
A known-plaintext attack on a symmetric cipher is easier than a
ciphertext-only attack. And a ciphertext-only attack is only possible
because even in that case, we know something about the plaintext; we know
things like frequency characteristics.
Thus, for very straightforward information-theoretic reasons, the better
the quality of our compression method, the less information is known to an
adversary about the contents of our plaintext messages. And the less the
adversary has to work with in an attack on our ciphers.
Thus, improvements in the quality of compression that are not normally
worth the effort simply to save storage space or transmission time can
still be relevant for cryptographic purposes, where the existence of any
available information about one's plaintexts is something to be fought
wherever possible.
As compression approaches perfection, the ciphertext-only attack
approaches becoming as impossible as cracking a one-time-pad. Of course,
the difference here is that physical randomizing devices let us actually
implement a one-time-pad; perfect compression, except in the trivial "Paul
Revere" case, is essentially impossible.
John Savard
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: the ACM full of Dolts?
Date: Wed, 27 Oct 1999 08:14:37 -0600
Reply-To: [EMAIL PROTECTED]
The review's comments seem in order.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.security,comp.security.misc,alt.cellular-phone-tech
Subject: SMARTCARD SECURITY NEWS ISSUE #7
Date: Wed, 27 Oct 1999 14:46:08 GMT
Smartcard security technical info page is updated at URL:
http://www.geocities.com/ResearchTriangle/Lab/1578/smart.htm
This page contains technical information and links about
smartcards and especially smartcard security (including satellite
cards, GSM SIM cards, phonecards, banking cards,
secure microcontrollers, smartcard standards,
and smartcard protocols). Big attention is held on smartcard attacks.
There is no commercial and marketing blah blah.
The Smartcard Security News Issue #7 is also launched.
Hadlines:
- The (Tamper And Monitoring Protection Engineering Research)
Lab at the University of Cambridge Computer Laboratory
- Design Principles for Tamper-Resistant Smartcard Processors
by Oliver Kommerling and Markus G. Kuhn
- An article about Eurochip by [EMAIL PROTECTED]
- ST1-64 Free Basic Stamp 1 interpreter for PIC 16F84
- nad much more...
Bo Lavare
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: This compression argument must end now
Date: Wed, 27 Oct 1999 11:15:54 -0400
Tim Tyler wrote:
> Anton Stiglic <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
> :> Steven Alexander <[EMAIL PROTECTED]> wrote:
>
> [compression before encryption]
>
> :> : However, it will not make a known plaintext attack anymore difficult.
> :>
> :> No. This is false. This is the /third/ time someone has raised this
> :> point - so perhaps it should get into the one-on-one FAQ.
>
> : As I have obseved, Mr. Tyler is talking about stream ciphers.
>
> You /may/ have observed it, but I didn't notice fast enough to correct
> your notion.
>
> Mr Tyler is *not* talking about stream cyphers. His comments refer to
> pretty much *any* type on cypher system, except ones where the key size is
> close to the size of the entire message.
>
> : If your cipher is a stream cipher, then an attacker gets less ciphertext
> : for sur (and the entropy of the source, which spits out bits, is greater
> : if you use compression).
>
> Block cyphers too. It really makes no difference at all.
>
> [block/stream]
>
> : It's important to distinguish the two cases, is the attacker getting
> : encryption of chunks of the message, or an encryption of the whole
> : message.
>
> I see no distinction worth mentioning in the context of this discussion.
If you were working on attacks on RSA, or ElGamal, based on mathematical
principals like FACTORING, Discret log problem, homomorphic property
of RSA, commun modulus of RSA, small exponents of RSA, big step giant
step algo's, etc..., etc... I think you would addapt the view I mentioned.
There is no good reason to discard this model for encryption schemes such
as the public key schemes that exist today. Furthermore, I would say that it
would be foolish to take on the other model for attacking such schemes.
Anton
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Unbiased One to One Compression
Date: Wed, 27 Oct 1999 16:25:15 GMT
In article <P1ER3.20$[EMAIL PROTECTED]>, gtf[@]cirp.org (Geoffrey T.
Falk) wrote:
>
>Please give an example of a compression algorithm that is "good" in
>the statistical sense, which does not have the "one-on-one property,"
>but which adds information systematically to the stream.
>By "good" I mean that the algorithm approaches the theoretically
>optimum compression ratio (the entropy) asymptotically, as the
>amount of input data increases.
I am not sure you know enough about compression to ask the
question correctly. But one compression method that many consider
very good for a large class of files is those involving the BTW ( Burrows
Wheeler Transform) I have tried unsuccessfully so far to make the BTW
transform reversible. In the sense take a list of characters and apply a
reverse transform on it. Even discarding the index not every file has a
reverse. So at present methods that use the BTW don't seem to be
able to be put in the One to One compression format. But I hope
I am wrong since this is one of my favorite methods if one can see
a way to make it one to one it would be really great.
>
>I think it is clear that if an algorithm adds information systematically
>to the stream, then it is simply not good statistically. Whether it has
>the o.o.o.p. is a different question. There are algorithms not having
>o.o.o.p. which approach the data's optimal compression ratio
>asymptotically. (Example: Add 1 random byte to the beginning of the
>file before applying a perfect compression. Strip this byte off
>during decompression.) And there are algorithms having o.o.o.p.
I maintain adding a random byte is more in the field of encryption.
We are looking at pure compression routines. You could also add
your random byte to a o o o p and get the best of both worlds
but in case you forgot this is about why would one use compression
that adds information for the attacker to use.
>which do not come close to their optimal ratio (example: The
>trivial pass-through compressor). In short, the o.o.o.p. and
>statistical "goodness" are practically unrelated,
>
>Again: Simply not being "one-on-one" itself, in general, only helps
>the attacker if he can guess X and then compute Comp(Decomp(X)).
>And if the set of "bad" messages (those for which Decomp(X) is
>undefined, or X != Comp(Decomp(X))) is sparse, this isn't even
>much help.
>
>For that matter, I have never seen a proof that David's method
>itself introduces no bias. Is a proof of this forthcoming?
IF you don't have the ability to see that a one to one mapping can
only contain the information that was in a file. There is really not
much I can do to help you. The proof is obvious. Either you have
the IQ to see it or you don't.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
** 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
******************************
