Cryptography-Digest Digest #195, Volume #11 Thu, 24 Feb 00 20:13:01 EST
Contents:
Re: Report Details Vast SPY Network (John Savard)
Re: Compression in the Real World (John Savard)
Re: Passwords secure against dictionary attacks? (Matt Baney)
Re: FIRST TIME! (Mok-Kong Shen)
Re: Implementation of Crypto on DSP (David A Molnar)
Re: Assistance needed ("Joseph Ashwood")
Re: NSA Linux and the GPL ("John E. Kuslich")
Re: Processor speeds. ("John E. Kuslich")
Re: - US "allows" encryption program online (Mok-Kong Shen)
SAC '2000 Call for Papers ("Tom Harper")
Re: How to Annoy the NSA ("Donald S. Crankshaw")
Re: - US "allows" encryption program online ("Charles R. Lyttle")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Report Details Vast SPY Network
Date: Thu, 24 Feb 2000 16:09:49 GMT
[EMAIL PROTECTED] (Dave Hazelwood) wrote, in part:
>Campbell said Microsoft, IBM, and a certain "large American microchip
>maker" were providing certain product features which allow the
>interception of information flow.
The Pentium III serial number?
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Compression in the Real World
Date: Thu, 24 Feb 2000 16:11:36 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
>However, if the source
>is known to consist of a particular finite set of possible
>messages, then one needs at most the ceiling of the logarithm
>(base 2) of the number of possible messages. If the messages
>aren't all equally probable, then fewer bits are needs to
>encode a sample drawn from that population. If context is also
>taken into account, sometimes it takes remarkably little
>information to encode a message: one if by land, two if by sea.
Yes, that's an important special case. However, it probably would not
be applicable to a commercial compression product.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Crossposted-To: comp.security.misc,alt.security.pgp
From: [EMAIL PROTECTED] (Matt Baney)
Subject: Re: Passwords secure against dictionary attacks?
Date: Thu, 24 Feb 2000 23:36:32 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Ilya wrote:
>> Is it secure to take two words and join them together, such as:
>>
>> crypto/life cyber@machine green-dog Loud!Music
>
>A phrase generated at random in the same way as
>"crypto/life cyber@machine green-dog Loud!Music", would probably be a
>secure passphrase. Just two words of it (such as "crypto/life") would
>almost certainly not be.
>
>As an example, "crypto", "life", "green", "dog", "loud", and "music"
>all appear in a 7854-entry wordlist I sometimes use, and "/" is one of
>about 10 or so characters likely to be used as the separator. So a
>*rough* estimate of the maximum entropy of, say, "crypto/life" against
>an attacker who knows (or can guess) the basic scheme, is about
>log2(7854 * 7854 * 10) = 29.2 bits.
>This will easily fall to a dictionary attack.
What if the space between words was removed and another character inserted at
regular intervals. For example
crypto life green dog loud music
becomes
cryp)toli)fe gree1ndog loud2musi2c
or maybe
cry9pto9lif9e gre!end@og lou(dmu(sic
or maybe
cr-yp-to-li-fe gr1ee2nd3og lo(ud)mu(si)c
Seems like it's still susceptible to brute force but a pure dictionary attack
wouldn't get this would it?
Matt Baney (206)-545-2941
SHAI Seattle, Washington [EMAIL PROTECTED]
=======================================================
On the Internet people may not be able to tell if you're a
dog or a fox, but they will know if you're an ass.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: FIRST TIME!
Date: Fri, 25 Feb 2000 01:09:06 +0100
Arthur Dardia wrote:
>
> Jean Pierre wrote:
>
> > This is my first time here.
> >
> > Could someone give me the simplest way to create a simple code to encrypt a
> > simple message for a communication to be delivered after my death.
> > I thought about something like one those card perforated with holes in
> > certain places on a square card andthat one can fill in with a short
> > message, and turn the card around to continue.
> > At the end, fill the empties with any characters.
> >
> > I saw this done when I was a kid, but I am not quite sure how to go about
> > it.
> > Any suggestions? :-)
> >
> > Thanks in anticipation
> >
> > JP.-
>
> Watch Con Air. He does it by cutting out the eyes of the people attending the
> last supper; however, it would be a pain in the ass to write the message so the
> appropriate letter is in the right spot for each eyehole. Oh well, I guess I'm
> just lazy.
>
> I'd be interested in a program that did this too.
It seems to me that you are somehow leading away from the part
of the original post that has solid connection with cryptology.
The turning grille does perform some non-trivial encryption.
I am not quite sure you are in possession of techniques to crack
it off the hand.
M. K. Shen
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Implementation of Crypto on DSP
Date: 25 Feb 2000 00:12:17 GMT
Paul Koning <[EMAIL PROTECTED]> wrote:
> RISC machines, especially machines like the Alpha. That's not true, I
> have
> the test cases to prove that, but it certainly is the case you have to
> study
> hard and know a lot to beat the best compilers.
One thing to keep in mind with applications like cryptography and
software floating point is that you generally have a very small amount
of code to optimize. This allows you to study the problem in depth,
and more importantly study the architecture with the problem in mind.
You can even go to bed dreaming about the assembly output if you like.
So after a while the optimizations just spring up, many of which
could not have been conceived of by most (any) compilers. Consider
the MMX-enabled IDEA due to Helger Lipmaa -- that takes advantage of
some possible parallelism in the algorithm itself which wouldn't
have been obvious just from the C code. Another example comes in the
form of optimizations for the ARM platform; you can do Cool Stuff by
manipulating the fact that every ARM instruction is conditional.
You do have to spend a lot of time, but the point is that your payoff
for crypto is likely to be larger than if you were trying to speed
up a GUI or other mammoth piece of code by using assembly. Both because
there will be more to find,a nd also because each improvement in a tight
loop yields a lot of speed.
-David
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Assistance needed
Date: Thu, 24 Feb 2000 16:28:44 -0000
I took a look at your site, and I think the most
advantageous thing to do is optimize your algorithm to
something faster.
Based on your site it seems that your algorithm far be
optimized as follows (and perhaps further):
take a character from the input stream
for each character in the key stream
add the key character to the input character
twiddle the low order bit of the temp character
end for
alter the key stream
This will be much faster than your current design if you
actually coded what you wrote. Based on this I suggest that
your entire security is based on the step of "alter the key
stream". Since you are coming to us for help on it, I would
recommend that you scrap your algorithm and go with
something more tested. Some very good examples are on the
AES site
http://csrc.nist.gov/encryption/aes/round2/r2algs.htm
Also XOR is not inherently weak, in fact OTP the only
provably secure method utilizes XOR. You might want to check
the spelling on your website, it get's pretty bad.
Joe
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: NSA Linux and the GPL
Date: Thu, 24 Feb 2000 17:50:11 -0700
No, no...
Anyone who obtains a security clearance has the rules explained to him IN NO
UNCERTAIN TERMS!!! These rules are periodically repeated during security
breifings after which all the participants are required to sign documents
indicating that they understand the rules and that they may be imprisoned,
sometimes after secret court hearings, if they violate these rules.
I have seen individuals fired for simply forgetting to lock a safe while the
left the room. Many ordinary defense workers are periodically scared half
to death by these spooks and their draconian penalties. How can this guy
get away with activities that would have landed the rest of us in jail for a
long time?
I have seen marine guards pull weapons on ordinary folk for simply not
showing a visitor's pass in the micro-second or two allowed after a young
marine made the request. I have heard stories of "detainees" in the
basement at Fort Meade. Smart asses who challenged the wrong authority at
the wrong time and lived a weekend incommunicado and scared that they might
never see the light of day.
Anyone who has ever submitted to this process knows what I am talking about.
He knew the rules, he deliberately violated these rules. THAT IS A
VIOLATION OF THE LAW (Title 18, I believe).
He ought to serve time. If I had done what he did, I would have served...I
guarantee!!
JK http://www.crak.com
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "John E. Kuslich" wrote:
> > Why is has John Deutch not been arrested and charged with violations
> > of the law regarding care of classified information?????????
>
> To what "law" are you referring? We have laws about espionage and
> sedition, but no Official Secrets Act.
>
> I agree that it was a terrible, inexcusable mistake, and should
> keep anyone from ever again putting Deutsch in a position of trust,
> but I don't see how he can be punished under the law.
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: Processor speeds.
Date: Thu, 24 Feb 2000 17:53:21 -0700
No problems.
Do these things come with ethernet and TCP/IP stacks??
I really know nothing about them, but the idea seems very exciting.
I would like to hear more.
JK
Mok-Kong Shen <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> John E. Kuslich wrote:
> >
> > This seems fantastic!!
> >
> > But how does one interconnect these systems and how does one get
specific
> > software to play on these systems?
> >
> > Are there assemblers or compilers available to the general public.
>
> I also like to know the answers. But I believe there are no prolbems
> of hardware interconnections, the processors are already performing
> the tasks of games. PVM, at most with some slight adaptations, should
> be able to give mechanisms to perform distributed computing with them.
> As compiler generation is nowadays a well understood field of CS,
> it shouldn't be a stumbling stone for such a project. Perhaps one
> could in the first phase use an interpreter, accepting the trade-off
> of less efficiency.
>
> M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: alt.sources.crypto,talk.politics.crypto,us.legal
Subject: Re: - US "allows" encryption program online
Date: Fri, 25 Feb 2000 02:01:46 +0100
- Prof. Jonez� wrote:
>
>
> By Reuters
>
> Bernstein's lawsuit came about because under the old rules, a book containing
>computer
> source code could be shipped out of the United States without restriction, but the
>same
> source code posted on the Internet or put on a floppy disk could not be "exported"
>without
> a license.
It seems that the 'logic' of the bureaucrats in the above described
issue is of the same genre as that which is reflected in the
following two sections of the proposed final EAR:
(2) You may not knowingly export or reexport source code or products
developed with this source code to Cuba, Iran, Iraq, Libya, North
Korea, Sudan or Syria.
(3) Posting of the source code on the Internet (e.g., FTP or
World Wide Web site) where the source code may be downloaded
by anyone would not establish "knowledge" of a prohibited
export or reexport, including that described in paragraph
(e)(2) of this section. In addition, such posting would not
trigger "red flags" necessitating the affirmative duty to
inquire under the "Know Your Customer" guidance
provided in Supplement No. 3 to part 732 of the EAR.
Note that anyone publishing something on his web page almost
certainly KNOWS that the information he presented is thereby
made freely accessible from everywhere, including in particular
the terrorists' countries. The very existence of this knowledge
(concerning the said availability, i.e. the export to the
terrorists' countries) is however NEGATED (i.e. 'defined' to be
non-existent) in section 3 above.
If this kind of 'negation' could be applied elsewhere, then nobody
committing any crimes need ever be sentenced.
M. K. Shen
======================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "Tom Harper" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.research
Subject: SAC '2000 Call for Papers
Date: 25 Feb 2000 00:23:55 -0000
CALL FOR PAPERS
SAC 2000
Seventh Annual Workshop on Selected Areas in Cryptography
to be held at:
University of Waterloo
Waterloo, Ontario, Canada
Dates: August 14-15, 2000
Co-Chairs:
Doug Stinson, University of Waterloo
Stafford Tavares, Queen's University
Workshop Themes:
1. Design and analysis of symmetric key cryptosystems.
2. Primitives for private key cryptography, including
block and stream ciphers, hash functions and MACs.
3. Efficient implementations of cryptographic systems
in public and private key cryptography.
4. Cryptographic solutions for web/internet security.
Program Committee:
D. Stinson U. of Waterloo, Canada
S. Tavares Queen's U., Canada
L. Chen Motorola, U.S.A.
H. Heys Memorial U. of Newfoundland, Canada
L. Knudsen U. of Bergen, Norway
S. Moriai NTT Labs., Japan
L. O'Connor IBM Zurich
S. Vaudenay EPFL, Switzerland
A. Youssef U. of Waterloo, Canada
R. Zuccherato Entrust Technologies
Instructions for Authors
Submissions must consist of an extended abstract of at most 15
double-spaced pages, clearly indicating the results achieved,
their significance, and their relation to other work in the area.
Authors can either email one copy of a Postscript file to
[EMAIL PROTECTED] or send ten copies of the extended abstract to
SAC 2000
c/o Stafford Tavares
Department of Elect. and Computer Eng.
Queen's University
Kingston, Ontario K7L 3N6
CANADA
Important Dates:
Submission Deadline May 1
Notification of Acceptance June 19
Workshop Dates August 14-15
Deadline for Proceedings September 18
Proceedings
It is intended that the Proceedings will be published by
Springer-Verlag in the Lecture Notes in Computer Science
(LNCS) Series. In order to to be included in the Proceedings,
papers must be presented at the Workshop. As in previous years,
the Workshop Record will be available to participants during
the Workshop.
For further information contact:
Doug Stinson, University of Waterloo [EMAIL PROTECTED]
Stafford Tavares, Queen's University [EMAIL PROTECTED]
Conference web page:
http://www.cacr.math.uwaterloo.ca/conferences/2000/SAC2000/announcement.html
------------------------------
Date: Thu, 24 Feb 2000 20:04:24 -0500
From: "Donald S. Crankshaw" <[EMAIL PROTECTED]>
Subject: Re: How to Annoy the NSA
Jerry Coffin wrote:
>
> In article <879tg8$q95$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
>
> [ ... ]
>
> > The safety of RSA appears to depend on the
> > difficulty of factoring large numbers. This
> > factoring is considered very likely to be a
> > hard problem although it is not yet proven to
> > be so. It is also not proven that the safety
> > depends solely on the factoring. The main
> > point of Peter Shor's famous algorithm is that
> > it demonstrates that a quantum computer
> > could factor large numbers efficiently (i.e.
> > within polynomial time). For anyone who's
> > interested, a good intro to codes and their
> > vulnerability is Simon Singh's "The Code Book".
>
> You're still ignoring reality: we already KNOW exactly what effect a
> quantum computer has on the amount of time it takes to factor a number
> of a particular size. We already have the technology to continue use
> RSA, and be protected from an attach using a quantum computer. People
> using 2048-bit keys with RSA are already safe, even though the threat
> is still purely theoretical.
>
I know this is an old thread, but I'm new to this group and I came
specifically looking for views by Cryptologists on Quantum
Computation. I work on a Quantum Computation project, so I may be able
to contribute something to this discussion.
For the record, I am not an Algorithms person. My work is more
focused on the design of the qubit (the quantum system which stores
the bit) itself and on the means of rotating it. Thus, I tend to be
more focused on the physics and engineering than the algorithms, but I
know enough about the Shor algorithm to say that 2048 bits is
definitely not safe; at least not if the project I'm working on proves
successful.
It's important to say first that Quantum Computation is not like
Parallelism, where you simply throw more power at the problem. What
QC does is allow you to completely redefine how you approach the
problem. In the case of the Shor algorithm, let's say you have b bit
product of 2 primes. A quantum computer can solve the problem in
O(b^2) quantum operations. A classical computer requires
O(exp(cb^(1/3)). This is the number field sieve algorithm, the best
known classical one. (It's much better than the slowest one, which is
O(exp(b/2), and would take longer than the lifespan of the universe to
factor a 2048 bit number.) I must admit that I know next to nothing
about this algorithm aside from its order (mainly for comparison's
sake), so I cannot say how quickly it could factor a 2048 bit number
(mainly I don't know c). The quantum algorithm, however, would
require on the order of 4 million quantum operations. The project I'm
working on has an approximate quantum operation time of 10 ns, so
we're talking on the order of .04 s to factor a 2048 bit number. Now
I'm using the term "on the order of" a lot since there are all sorts
of factors I'm leaving out, not to mention pre- and postprocessing.
Like I said, I don't spend a lot of time working with the algoritms.
Now, how feasible is this? Oh, the most optimistic estimate certainly
wouldn't consider it possible in less than ten years. And that's
being _very_ optimistic, assuming one of the solid state propositions
works as well as we hope and that it scales quickly and easily. More
realistically, maybe 25 years. There's also the very real possibility
that it won't work at all--we'll be bogged down by the decoherence
problem.
Still, by the time quantum computation becomes feasible, 2048 bits
will not be enough. And while you can increase the number of bits, it
won't buy you as much as it once did.
Oh, and as for the original subject line, "How to Annoy the NSA"...,
who do you think funds all this quantum computation research anyway?
Sincerely,
Donald S. Crankshaw
http://www.mit.edu/~dscrank
------------------------------
From: "Charles R. Lyttle" <[EMAIL PROTECTED]>
Crossposted-To: alt.sources.crypto,talk.politics.crypto,us.legal
Subject: Re: - US "allows" encryption program online
Date: Fri, 25 Feb 2000 01:03:11 GMT
It looked to me like this is an attempt to avoid going to court and
setting a precident. I hopes he keeps it in court.
- Prof. Jonez� wrote:
>
> Professor allowed to post encryption program online
>
> By Reuters
>
> February 24, 2000, 11:00 a.m. PT
>
> WASHINGTON--The United States will let a computer scientist put instructions for
>writing a
> powerful computer data-scrambling program on his Web site, but his high-profile
>lawsuit
> challenging U.S. export restrictions on encryption may continue, his lawyer said
>today.
>
> President Clinton in January dramatically liberalized once-strict U.S. export limits
>on
> encryption programs, which scramble information and render it unreadable without a
> password or software "key." The changes recognized that encryption, used in
>everything
> from Web browsing software to cellular telephones, has become essential for securing
> e-commerce and global communications.
>
> The move also followed a May 6 decision by a three-judge panel of the U.S. Ninth
>Circuit
> Court of Appeals that the old rules barring University of Illinois professor Daniel
> Bernstein from posting instructions for his "Snuffle" program on the Internet were an
> unconstitutional violation of the scientist's freedom of speech.
>
> But in January, the full court asked the panel to reconsider the ruling in light of
>the
> new Clinton policy.
>
> In a private advisory letter sent last week, the Commerce Department confirmed that
>the
> new encryption export policy permitted Bernstein to post instructions, called source
>code,
> for his program on the Internet for all to see. Any other computer programmer could
>easily
> compile the source code into a functioning program.
>
> "In light of the changes in licensing and review requirements for publicly available
> source code, the new regulations do not interfere with his planned activities as you
>have
> described them," the Commerce Department letter said in response to a letter from
> Bernstein's lawyer.
>
> Under the old rules, Bernstein had to obtain an export license for each person who
>wanted
> to view his Web site from outside the United States--an impossible task given the
>Net's
> global reach. But the new rules allow anyone to post encryption source code on the
> Internet as long as they also send a copy to the government and do not charge
>royalties
> for use of the code.
>
> "We are still considering our options," said Cindy Cohn, Bernstein's lawyer. Cohn
>said the
> Commerce Department letter failed to clear up some questions about the new rules.
>
> The department did make it clear that a Web site that merely picked up code posted by
> someone else, a practice known as mirroring, would not be held responsible for
>following
> the export rules. And Bernstein or others would not have to notify the government
>again
> each time they posted bug fixes or updates.
>
> Bernstein's lawsuit came about because under the old rules, a book containing
>computer
> source code could be shipped out of the United States without restriction, but the
>same
> source code posted on the Internet or put on a floppy disk could not be "exported"
>without
> a license.
>
> --
> =======================================
> Free Directory Assistance - NumberFinder.com
> Free Email Address - Alias.org
> Free Trademark Searches - TrademarkSearch.org
> Free Multi-Auction Searches - AuctionFeed.com
> 5� Phone Calls to Australia - SuperPhone.net
> =======================================
--
Russ Lyttle, PE
<http://www.flash.net/~lyttlec>
Thank you Melissa!
Not Powered by ActiveX
------------------------------
** 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
******************************
