Cryptography-Digest Digest #573, Volume #9 Fri, 21 May 99 06:13:04 EDT
Contents:
Re: Can a Java or Active-x program get your keys?????? (David A Molnar)
Re: Looking for pointers (David A Molnar)
Crypto Book Wins Award (William Stallings)
Re: Random permutation (Stephen August Weis)
Re: Encryption starting ([EMAIL PROTECTED])
Re: RC4 based hash ([EMAIL PROTECTED])
Re: Reasons for controlling encryption ("Markku J. Saarelainen")
Off Topic (rosi)
Re: RSA Cryptography Question (Hideo Shimizu)
Re: Biprime Cryptography, Part II (kurt wismer)
Where can I find ? (Marcin Kontak)
Re: Reasons for controlling encryption ("Douglas A. Gwyn")
Re: Reasons for controlling encryption ("Douglas A. Gwyn")
Re: Complexity Question (Stephen Weis)
Re: Question about Beale Ciphers ("Douglas A. Gwyn")
Re: prime numbers and the multplicative inverse (Harald Weidner)
Re: Standard of encryption required for new process (Giuliano Bertoletti)
Re: Reasons for controlling encryption (Andrew Haley)
----------------------------------------------------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Can a Java or Active-x program get your keys??????
Date: 21 May 1999 01:20:38 GMT
Vernon Schryver <[EMAIL PROTECTED]> wrote:
>>picking up your key databases would be all that much more difficult.
> Well, I guess so, provided you are dumb or naive enough to swallow
> Microsoft's oh so convenient blurring of the differences between
> authentication and authorization and turn on ActiveX.
"this file is mostly harmless."
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Looking for pointers
Date: 21 May 1999 01:10:57 GMT
Steven Alexander <[EMAIL PROTECTED]> wrote:
> Grab a copy of the sci.crypt FAQ(It's posted regularly). Also, "Applied
> Cryptography" by Bruce Schneier is a good introductory text on cryptography.
> As far as your math goes, you'll probably want to freshen up on your
> calculus a bit. It's not necessary to understand the forementioned book,
> but you'll need it before reading the academic papers that you may find.
> www.counterpane.com has a good collection of academic papers on crypto.
Calculus ? Only if you're using "calculus" as a byword for "mathematical
maturity", I think. Either that, or maybe you're considering analysis
of running times as 'calculus' ?
There seem to be a few distinct areas of math which are helpful
for crypto, broken down by what exactly it is in crypto that you
wish to study :
abstract algebra and number theory -- shows up in discussions of RSA or
ElGamal or Rabin or your favorite
schem whose security is based on
some number theoretic problem.
Koblitz's book is an example of this
approach to crypto. It may be a bit
advanced if you aren't familiar with
math textbooks; Oystein Ore has a nice
friendly "Number Theory and Its History"
which may be worth reading first.
linear algebra -- not directly applied much (except perhaps for secret
sharing schemes), but very helpful for packaging and
generalizing other results. Like, do you want to
do shamir secret sharing with more than one value at
once? Let the polynomial be a vector-valued function and
it works.
Also very helpful for cryptanalysis, especially as this
shades into lattices. Not to mention differential
equations. :-)
Your mileage will vary with books. at least mine has.
do try to find one which uses dual spaces, though.
computational complexity -- the concept of a "reduction." Why
reductions help us 'prove' security. How to
do reductions. How to spot bad reductions.
The classic overview is Garey and Johnson
"Computers and Intractability : A Guide To
The Theory of NP-Completeness", but supplement
with a textbook on intro to comp. theory
probability and statistics -- lots of arguments which depend on
saying things about probability show up.
would be nice to know how far you can
throw them. I can't suggest books here.
Anyone have any favorites?
computational number theory / algorithm analysis -- evaluating efficiency
of number-theoretic
algorithms. this can
be a royal pain.
any other pet area of math
which has fun properties -- constructions for hash functions and other
primitives come from all kinds of places.
I just found a paper by D.R. Stinson which
discussed constructions of hash functions
with respect to something called a
'balanced independent block diagram.'
I don't know anything about these yet, but
I have a feeling I should probably learn.
What else ? what do people think of these categories? and what would
you recommend to someone starting out in each of 'em? I know the FAQ
has a list of books -- is that being updated?
Thanks much,
-David Molnar
------------------------------
From: [EMAIL PROTECTED] (William Stallings)
Subject: Crypto Book Wins Award
Date: Thu, 20 May 1999 09:36:01 -0400
My book,
Cryptography and Network Security: Principles and Practice, Second Edition
Prentice-Hall, 1999, ISBN 0-13-869017-0
has just received the 1998 award for the best Computer Science and
Engineering textbook of the year, awarded by the Text and Academic Authors
Association.
Bill Stallings
| | Descriptions, errata sheets and discount order info |
| Bill Stallings | for my current books and |
| [EMAIL PROTECTED] | information on my forthcoming books at |
| | http://www.shore.net/~ws |
------------------------------
From: Stephen August Weis <[EMAIL PROTECTED]>
Subject: Re: Random permutation
Date: 21 May 1999 01:38:20 GMT
Christopher <[EMAIL PROTECTED]> wrote:
: |:| I had an idea on how to permute a range of numbers [0..n] while
: |:| minimizing calls to a random number generating function. Basically, j
: |:| ust use the random number as an index into an array. If it is already
: |:| filled, increment modulo n to the next available slot.
: I would think that the distribution wouldn't be uniform. Suppose the first
: call of rand16() returns 1, now an index of 2 has a 2/16 probablility
: instead of 1/16. After 2 is chosen, 3 has a 3/16 and so on.
You're right. The second random index has a higher probability of being
right after the first random index than anywhere else. If the first index
was i there is a 2/n chance the second index will collide with i or
be equal to i+1, both putting the second element into i+1.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Encryption starting
Date: Fri, 21 May 1999 01:43:57 GMT
> I never said it doesn't. Yes, I do own the book and I do believe that
> it is a well-written book *for certain purposes*. It covers the basics
> of cryptography, but not cryptanalysis. I am not able to find a
> detailed description of either linear or differential attacks in the
> book. Can you?
Page 285 and 290 have a brief description of it. Yes the paper on DES
(16 round) is a good paper too. The latter is most likely better to
start with.
> You can read the analysis of the algorithm, but do you actually
> understand what it means? You may have an intuitive sense that a
> algorithm is strong, and it very well could be, but you cannot
describe
> why it is strong and how it resists cryptanalysis.
>
Well I understand why RC5 is strong against linear analysis though, and
all I did was read the paper. This doesn't apply to other algorithms
(like CAST and Blowfish) as easily though...
> What they did not do was post long, rambling descriptions of every
> algorithm that they happen to think of and expect other people to
break
> it.
I didn't think my posts were long :)
> Your last statement shows how flawed your approach to cryptography is.
> You may understand how a technique applies to an algorithm in one
case,
> but you have no overall understanding of the topic, nor do you know
how
> to apply the knowledge you gain in one instance to another situation.
Well I understand how multiplication in a prime field is usefull (it's
a field not a group). I also know how primitive generators are usefull
too. I am not a retard because I am new at this.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RC4 based hash
Date: Fri, 21 May 1999 01:34:57 GMT
> I've seen that suggested before. But RC4 is not a very good hash
> function _by itself_, because each byte of the key only affects *some*
> table entries. Thus, some parts of the key might not affect a short
> sequence of RC4 output used as a hash, making it possible to produce
> collisions.
>
What if you cycled the RNG x number of times before producing output (x
= size of message).? Wouldn't that make the last bytes more effective?
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Subject: Re: Reasons for controlling encryption
Date: Thu, 20 May 1999 23:33:40 -0700
Actually ... a real story ...
Once Bob asked Alice, if Bob knew a very unique language called "Boblingo" that
nobody else knew, should Bob be able to teach Alice how to speak and understand
this "Boblingo" in order to communicate in this language . Alice's answer was
promptly "Yes". This just gives an interesting insight ...
What do you think?
------------------------------
From: rosi <[EMAIL PROTECTED]>
Subject: Off Topic
Date: Fri, 21 May 1999 00:24:44 -0700
Sorry for this posting. However, some people might be interested or
know people who might.
I am offering my cryptographic invention for 'free', i.e. If you
are interested in paying for the filing and maintenance in exchange
for the exclusive patent rights, please go to the news group
alt.inventor
and look for a thread, subject titled:
Cryptographic Invention
Sorry for any inconvenience this causes.
--- (My Signature)
------------------------------
From: Hideo Shimizu <[EMAIL PROTECTED]>
Subject: Re: RSA Cryptography Question
Date: Fri, 21 May 1999 13:56:26 +0900
Because, for all m<n
m ^ phi(n) equiv m mod n
Hideo Shimizu Toshiba Labo
HypSoft wrote:
>
> Does anyone know the reason that the RSA algorithm's encrypting process is
> one-to-one?
>
> --
>
> Andrew Hamilton
> [EMAIL PROTECTED]
------------------------------
From: kurt wismer <[EMAIL PROTECTED]>
Subject: Re: Biprime Cryptography, Part II
Date: Thu, 20 May 1999 22:37:53 GMT
Mok-Kong Shen wrote:
>
> John Savard wrote:
> >
> > During the year 2000, the patent on the encryption system devised by
> > Drs. Rivest, Shamir, and Adleman will expire. As the common name of
> > that encryption system is also part of the name of the company owning
> > the patent, this name may be subject to trademark protection.
> >
> > So some people were looking for another name for that particular
> > public-key algorithm.
>
> Simple: Any permutation of the three characters.
lets see if we can't avoid alphabetical order though... ARS Encryption
just doesn't sound right...
--
"close your eyes and bow your head
i need a little sympathy
cause fear is strong and love's for
everyone who isn't me"
------------------------------
From: Marcin Kontak <[EMAIL PROTECTED]>
Subject: Where can I find ?
Date: Fri, 21 May 1999 09:38:23 +0200
Where can I find paper:
C. Adams "Good S-Boxes are hard to find"?
Thanks
My e-mail: [EMAIL PROTECTED]
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Reasons for controlling encryption
Date: Fri, 21 May 1999 07:43:47 GMT
Mark E Drummond wrote:
> one argument _against_ it was that it would let the "bad guys" _inside_
> the organisation traffic inappropriate material. eg encrypting
> classified material or pictures of your neighbors daughter sans
> vetements and emailing it to your friend in <pick you enemy's country>.
Of course, they can traffic in such stuff without encryption anyway.
Also, it is easy enough to get and use encryption/decryption tools
other that what is "officially" provided.
And finally, such tools can be used "within" the officially approved
encryption.
I.e., trying to control what encryption is "officially" allowed,
as with the infamous key escrow schemes, is useless against real
crooks -- the only use it has is against innocent people.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Reasons for controlling encryption
Date: Fri, 21 May 1999 07:52:15 GMT
Mike McCarty wrote:
> [sarcastically:] Everyone knows that only about 5 people in the world
> could ever have discovered the atomic bomb, and they all live here.
> So if we just never tell anyone, no one else will ever find out.
One problem with exaggerating your point is that it makes a
caricature of your own position. Nuclear weapon design isn't based on
just one secret; however, there are indeed very many engineering
secrets involved in building *effective* nuclear weapons, and it cost
much to discover them. So it makes sense to protect such secrtes.
Similarly with real secrets of cryptography, and yes, there are many.
> The NSA, far from wanting to promote freedom and liberty by
> protecting our country, assumes that WE THE PEOPLE are the biggest
> criminals they must protect the gov't from.
Funny, none of the many NSA employees of my acquaintance believe any
such thing. Where do you get your "information"?
There are undoubtedly many politicians who use governmental power to
control the populace. But that isn't remotely within NSA's charter.
------------------------------
From: Stephen Weis <[EMAIL PROTECTED]>
Subject: Re: Complexity Question
Date: 21 May 1999 08:18:38 GMT
Mike Murray <[EMAIL PROTECTED]> wrote:
: For a given algorithm, O(n) is in terms of the size of a variable
: n. How do we define the size of n? Is it the actual integer value of
: n, or is it the size of n in terms of length in bits? (which would
: actually be log(base 2) of n). For example:
In most cases you are concerned with the runtime of an algorithm
in relation to the length of the input. You can fall into a trap by
mistaking the value of a number for the size of it. For example, say
you just want to print out every number 1..N. You could easily think
that this is always a O(N) problem. In reality, it depends on the base
N is given in.
Assuming it is given in binary, each of those numbers will have
length n=log-2(N). Just printing out each bit of each number would
take O(2^n) time. There is one exception if your input is given
in unary. Then the length of each number is the same as its value
and your runtime would be O(N^2).
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Question about Beale Ciphers
Date: Fri, 21 May 1999 08:05:39 GMT
Frank Sewald wrote:
> I heard that one person managed to complete some kind of partial
> decryption that resulted in the text string "endofmyjoke".
I hadn't heard that one, but Gillogly (Cryptologia V4 N2 p116) found
a string of 14 consecutive letters from the alphabet (DEFGH...) via a
trial decryption with the Declaration of Independence, which he took
as evidence that (a) the DOI was used and (b) the message was a hoax.
It should be noted that by sufficiently obscure manipulations, any
sort of message can be extracted from even random text, so short
coherent strings like "endofmyjoke" aren't significant unless they
result directly from a *simple*, well-defined decryption scheme.
------------------------------
From: [EMAIL PROTECTED] (Harald Weidner)
Subject: Re: prime numbers and the multplicative inverse
Date: 21 May 1999 09:00:40 GMT
In article <7hrgi1$1or$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>I haven't been able to find an answer to this question. Why does IDEA
>use a prime field for it's multiplication?
There have already many answers to that question being posted, but
all of them understood the question in an other way than I did.
A finite field does not necessarily need to be a prime field,
but:
1. There exists a fast algorithm for finding the multiplicative
inverse of a (nonzero) field element; for other finite fields,
the algorithms are slower.
2. Since the IDEA calculations operate on 16 bit words, a field
with a multiplicative sub-group of 2^16 elements was needed.
With the chosen field, the isoporphism between the 2^16
16-bit-words and the non-zero field elements is _very_ simple.
3. The three operations used in the IDEA cypher operation are
chosen in a way that certain security aspects can easily be
proven, mainly confusion and diffusion.
--
Harald Weidner http://www.ifi.unizh.ch/~weidner/
------------------------------
From: Giuliano Bertoletti <[EMAIL PROTECTED]>
Subject: Re: Standard of encryption required for new process
Date: Fri, 21 May 1999 11:13:06 +0200
>
> What I'd be most grateful is for any type of cryptography/encryption test to
> be made on the encrypted files (not the actual procedure) produced by this
> program. I feel I do not have enough experience myself in the actual
> testing of this process to be able to directly compare how well it performs
> against well known encryption standards such as Blowfish or DES.
The point is that bad cryptography looks and feels just like good cryptography.
Any test on the produced output of any non trivial algotithm probably looks just
as random as the one produced by a strong cipher.
There are some requirements for a program to gain respectability:
(1) source code available, or at least the details of the encryption algorithm
and the protocol used (which could be acquired anyway by any malicious cracker
just disassembling your code, so don't count on the secrecy of your algorithm).
(2) support of well known strong block/stream ciphers. People are much likely to
trust a well studied public algorithm.
Consider that there are already many products (some available for free) which
satisfy these requests.
Kind regards,
Giuliano Bertoletti
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Andrew Haley)
Subject: Re: Reasons for controlling encryption
Date: 21 May 1999 09:10:48 GMT
Jerry Park ([EMAIL PROTECTED]) wrote:
: I've tried to conceptualize the reason for US export restrictions without
: success. It appears to only hinder US companies from developing and
: marketing encryption systems. It doesn't prevent non US companies from
: developing and marketing encryption system -- inside or outside of the US.
: (There are no import restrictions).
Yes, but don't forget that other countries which have treaties with
the US have similar export controls. This is not just a US problem.
: So the policy only harms US citizens while encouraging development
: of encryption systems outside the US. How can this help the US
: intelligence or law enforcement?
It's been more successful than you think. Were it not for export
controls, we may by now have had secure digital mobile telephones.
Much intelligence about the former Soviet Union came from
eavesdropping mobile telephones in other countries (particularly in
the third world) without a secure comms infrastructure. The
intelligence agencies don't want this to source of information to dry
up.
: Terrorists and other criminals are as able as anyone else to develop
: encryption systems, so the restrictions do not hinder them.
A terrorist organization cannot simply go to the corner store and buy
secure telephones. Yes, with software from the net, a PC, and a
couple of soundcards they might be able to assemble something
functionally equivalent but much less portable.
A well funded terrorist or criminal organization might be able to make
such things itself or buy them on the black market, of course.
: Since they can purchase any such systems from companies not in the
: US, they don't even have to develop such systems.
The export controls mean that there is no standard way to interoperate
secure telecomms. This hampers use just as well than controlling the
availability of hardware.
Andrew.
------------------------------
** 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
******************************
