Cryptography-Digest Digest #702, Volume #10 Wed, 8 Dec 99 00:13:01 EST
Contents:
Re: NSA future role? (CLSV)
Re: Encrypting numbers? (Thanks all!) (Michael Groh)
Re: NSA future role? (CLSV)
Re: Frequency results of twofish and serpent. (Johnny Bravo)
Re: NSA should do a cryptoanalysis of AES (Kenneth Almquist)
"Ciphertext-only Cryptanalysis of Enigma" (JPeschel)
New Courses in Information Security at RMIT (Serdar Boztas)
Re: Random Noise Encryption Buffs (Look Here) (Dave Knapp)
Re: Random Noise Encryption Buffs (Look Here) (Dave Knapp)
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: Paradise shills?? ("Douglas A. Gwyn")
Re: Encrypting numbers? (Thanks all!) ("Douglas A. Gwyn")
Re: Frequency results of twofish and serpent. ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: CLSV <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.nsa
Subject: Re: NSA future role?
Date: Wed, 08 Dec 1999 02:09:57 +0000
Medical Electronics Lab wrote:
> CLSV wrote:
> > albert wrote:
> > > If you walk into the library of the University of Michigan, you can actually find
> > > all you need to know as far as how to make a nuclear bomb.
> > One of those myths started by popular science magazines.
> [...] The hard part isn't the knowledge. The hard part is the
> material. You need specific isotopes in large enough quantities
> to create a nuclear weapon. The knowledge of how to separate
> those isotopes is also in the library.
There are enought countries that have the raw material that
would have build nuclear weapons if it were so easy. There is a
huge gap between reading theoretical principles in a (library) book
and building a nuclear weapon. The devil is in the details.
> Iraq's Hussien has built quite a few plants that separate out
> U235, and he's built at least one small reactor to create Pu.
And strangely enough Iraq had to depend on the *really* old documents of
the Manhattan project instead of using the much easier obtainable
library books.
Regards,
Coen Visser
------------------------------
From: [EMAIL PROTECTED] (Michael Groh)
Subject: Re: Encrypting numbers? (Thanks all!)
Date: Tue, 7 Dec 1999 21:20:19 -0500
Gotcha! Particularly if the numeric portion (such as a date, or time)
occurred in the same part of a standard message, it'd lend itself to a
crib, especially since the cryptanalyst would know the date and time the
message was sent, or at least, the date and time the message was
intercepted.
Thanks for the correction!
- Mike
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> On Tue, 7 Dec 1999 09:01:43 -0500, [EMAIL PROTECTED] (Michael
> Groh) wrote:
>
> >Even if we spell it out:
> >"DollarSignOneFourPointThreeSeven" it's a much longer message. I hadn't
> >considered that this makes the crypanalysis job much harder as well!
>
> Of course, you mean much _easier_.
>
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.nsa
Subject: Re: NSA future role?
Date: Wed, 08 Dec 1999 02:23:32 +0000
albert wrote:
> > One of those myths started by popular science magazines.
> Nope, not a myth, it's true. I will concede to the post above, stating that
> measurements, and details are hidden, which is the impeding stumbling block to making
> one, but if you want concepts etc,, it's all there.
Ok, I can agree with that.
> > And why wouldn't private sector companies make any mistakes?
> Accountability. Profit. NASA has lost about $2Billion thus far on Mars stuff. Any
>of
> them fired? No. If it was the private sector, performance and reward are linked,
>not
> so in the public sector.
Hmm, my opinion is that especially in big corporations large
amounts of money are wasted on useless pet projects, ego-mania,
stupidity, fraud et cetera. The problem is that a corporation
isn't publicly accountable for such losses. They rather hide
them in their incredibly complex annual reports to keep the
faith of their customers, creditor, share holders. At rare times we
get to see some of the mistakes if they are big enough
(e.g. Barings bank). I think that the problems that NASA has are more
related to the size and structure of the organization than on the
difference between private and public sector.
Regards,
Coen Visser
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Frequency results of twofish and serpent.
Date: Tue, 07 Dec 1999 21:37:29 GMT
On Tue, 07 Dec 1999 22:58:38 GMT, albert <[EMAIL PROTECTED]> wrote:
>I took an encryption of some text with twofish and serpent (straight
>ECB). I then did a frequency count of the results. I'm shocked (well,
>not really) on how evenly distributed the values are. Here are my
>results: Based on encryption of a few random text files that are about
>200K in size. No, this is not the most scientific of test methods, not
>claiming it is, just some info to pass along... Good to note that the
>standard deviation is very low; with highs being 6.20% and lows being
>5.90% on both algorithms (rounded).
>
>Albert.
This is to be expected, if it were otherwise something would be
seriously messed up. The biggest such analysis I know of is the one
that showed the bias in RC4, each character has a (1/256)+(1/2^256)
chance of being a duplicate of the previous character. This is the
result of billions of bytes of ciphertext being analysed. It was just
interesting to note, but not of any practical use.
Best Wishes,
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED] (Kenneth Almquist)
Subject: Re: NSA should do a cryptoanalysis of AES
Date: 8 Dec 1999 02:56:50 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote:
> You don't think 56-bits is a slightly small figure? Even for its day?
> I'm not sure if such an obvious restriction qualifies as a "trapdoor",
> since it's out in the open, but it is certainly a weakness.
One problem with a hardware encryption standard is that there is a
significant chicken and egg problem. Most people won't use it unless
implementations are cheap and available, but hardware is expensive
unless there is a mass market. Consider Ethernet as an example. It
is pretty horrible from a security point of view because it is so easy
to tap into. An obvious solution is to encrypt the traffic. and due
to the high data rate hardware encryption is the obvious choice. DES
has failed in this market because it is too expensive for manufacturers
to make it a standard feature on Ethernet cards. Manufacturers could
offer it as an extra cost option, but then most customers would not
buy it, because the ability to encrypt data is pointless unless the
system you are talking to has the ability to decrypt it.
An alternative to placing DES hardware on Ethernet cards would be to
build it into the CPU. DEC included some instructions on its VAX
machines which it knew would be totally useless to many of its
customers. (The instructions for binary coded decimal arithmetic
come to mind.) But DEC didn't find it worth while to include DES in
the VAX instruction set. As far as I know, every single computer
manufacturer reached the same conclusion: DES was too complex for
them to implement at a reasonable cost.
There has been some discussion in this newsgroup about Microsoft
products which use encryption algorithms that can be cracked in
seconds. If Intel had included DES encryption and decryption in the
x86 instruction set, those Microsoft products would probably have been
a lot more secure.
The design of DES involved an engineering tradeoff between security
and low cost. When DES was standardized, the 56 bit key was sufficient
for almost all applications. For that matter, I doubt that the 56 bit
key size of DES is responsible for very many security compromises today.
On the other hand, DES encryption hardware did not achive the ubiquity
that one might have hoped, leaving people with the options of:
1) Encrypt using DES hardware (too expensive),
2) Encrypt in software (slow if you use a secure algorithm--remember
that computers have gotten a lot faster in recent years), or
3) Don't encrypt your data, and hope for the best.
Certainly there would have been some benefit to making DES use a
longer key, if that could have been done without increasing the cost
of implementing DES. But there was also a potentially huge benefit to
making DES cheaper to implement, if that could have been done without
harming security. I don't see any reason to criticize the security/
cost tradeoff that the designers of DES made.
Kenneth Almquist
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: "Ciphertext-only Cryptanalysis of Enigma"
Date: 08 Dec 1999 03:20:59 GMT
As I promised yesterday, I've added
Jim Gillogly's "Ciphertext-only
Cryptanalysis of Enigma" to my
site. This paper originally appeared
in <i>Cryptologia</i>, October 1995;
Volume XIX, Number 4. You'll find
the paper and follow-up letters from
Erskine and Gillogly in the new
"Historical Ciphers" page.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
Date: Wed, 08 Dec 1999 11:40:00 +1100
From: Serdar Boztas <[EMAIL PROTECTED]>
Crossposted-To: comp.theory,sci.math,aus.mathematics,aus.education
Subject: New Courses in Information Security at RMIT
==============7C54AA42338E11BBBDDD8780
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
http://www.ma.rmit.edu.au/kepler/pgrad/InfoSec.html
E-mail [EMAIL PROTECTED] (until 16 December) or the Office of Prospective
Students at [EMAIL PROTECTED]
The closing date for applications is 20 January 2000
RMIT UNIVERSITY ANNOUNCES NEW COURSES IN INFORMATION SECURITY
Graduate Certificate in Information Security,
Graduate Diploma in Information Security and
Master of Applied Science (By Coursework) in Information Security
The development of the INTERNET, E-Commerce, Electronic Banking,
EFTPOS, etc. has resulted in industry demand for trained professionals
who can work in technical and managerial roles in addressing security
risks in this new and exciting field.
The high level approach of the Graduate Certificate is designed
to provide managers of companies or departments with Information
Security needs with a strategic and practical overview of the
issues involved in the field.
The system level approach of the Graduate Diploma supplements
the Graduate Certificate and is mainly aimed at systems managers
by providing them with the principles underlying the components of
Information Security systems.
The detailed approach of the Masters program is mainly suited to
technical specialists who are interested in implementation and
critical evaluation of Information Security systems.
These are full fee paying courses.
Course Structure
GRADUATE CERTIFICATE in INFORMATION SECURITY
48 CREDIT POINTS = 4 12 CREDIT POINT SUBJECTS =
1 YEAR PART TIME = 1 SEMESTER FULL TIME
One Mathematics foundation subject from the list
MA 915 Discrete Mathematics 1A, MA 159 Mathematics for Computer Science
One Computer Science foundation subject from the list
CS 891 Computing Fundamentals, CS 840 Introduction to Java
Two core subjects
MA 840 Introduction to Information Security, MA 841 Case Studies in
Information Security
GRADUATE DIPLOMA in INFORMATION SECURITY
48 CREDIT POINTS = 4 12 CREDIT POINT SUBJECTS =
1 YEAR PART TIME = 1 SEMESTER FULL TIME
(after completing the Graduate Certificate)
Two core subjects
MA 842 Coding for Reliable Communications, MA 843 Cryptography and
Security.
Two electives from the following list
MA 844 Algebraic Coding and Decoding, CS 861 Introduction to Data
Communications,
MA 846 Information Theory for Secure Communications, MA 847 Smartcard
Cryptosystems.
MASTER OF APPLIED SCIENCE (by COURSEWORK) in INFORMATION SECURITY
48 CREDIT POINTS = 4 12 CREDIT POINT SUBJECTS =
1 YEAR PART TIME = 1 SEMESTER FULL TIME
(after completing the Graduate Diploma)
Two core subjects
MA 845 Advanced Topics in Cryptography, MA 848 Project I
Two electives from the following list
MA 844 Algebraic Coding and Decoding, MA 846 Information Theory for Secure
Communications, MA 847 Smartcard Cryptosystems, CS 830 Introduction to
Databases,
CS 447 Secure Electronic Commerce, MA 849 Project II
http://www.ma.rmit.edu.au/kepler/pgrad/InfoSec.html
==============7C54AA42338E11BBBDDD8780
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<HTML>
<A
HREF="http://www.ma.rmit.edu.au/kepler/pgrad/InfoSec.html">http://www.ma.rmit.edu.au/kepler/pgrad/InfoSec.html</A>
<P>E-mail <A HREF="[EMAIL PROTECTED]">[EMAIL PROTECTED]</A>
(until 16 December) or the Office of Prospective
<BR>Students at <A HREF="[EMAIL PROTECTED]">[EMAIL PROTECTED]</A>
<P>The closing date for applications is <B>20 January 2000</B>
<P><B>RMIT UNIVERSITY ANNOUNCES NEW COURSES IN INFORMATION SECURITY</B>
<P><B>Graduate Certificate in Information Security,</B>
<BR><B>Graduate Diploma in Information Security and</B>
<BR><B>Master of Applied Science (By Coursework) in Information Security</B>
<P>The development of the INTERNET, E-Commerce, Electronic Banking,
<BR>EFTPOS, etc. has resulted in industry demand for trained professionals
<BR>who can work in technical and managerial roles in addressing security
<BR>risks in this new and exciting field.
<P>The high level approach of the Graduate Certificate is designed
<BR>to provide managers of companies or departments with Information
<BR>Security needs with a strategic and practical overview of the
<BR>issues involved in the field.
<P>The system level approach of the Graduate Diploma supplements
<BR>the Graduate Certificate and is mainly aimed at systems managers
<BR>by providing them with the principles underlying the components of
<BR>Information Security systems.
<P>The detailed approach of the Masters program is mainly suited to
<BR>technical specialists who are interested in implementation and
<BR>critical evaluation of Information Security systems.
<P>These are full fee paying courses.
<P><U>Course Structure</U>
<P><U>GRADUATE CERTIFICATE in INFORMATION SECURITY</U>
<P>48 CREDIT POINTS = 4 12 CREDIT POINT SUBJECTS =
<BR>1 YEAR PART TIME = 1 SEMESTER FULL TIME
<P>One Mathematics foundation subject from the list
<P><I>MA 915 Discrete Mathematics 1A, MA 159 Mathematics for Computer
Science</I>
<P>One Computer Science foundation subject from the list
<P><I>CS 891 Computing Fundamentals, CS 840 Introduction to Java</I>
<P>Two core subjects
<P><I>MA 840 Introduction to Information Security, MA 841 Case Studies
in Information Security</I>
<P><U>GRADUATE DIPLOMA in INFORMATION SECURITY</U>
<P>48 CREDIT POINTS = 4 12 CREDIT POINT SUBJECTS =
<BR>1 YEAR PART TIME = 1 SEMESTER FULL TIME
<BR>(after completing the Graduate Certificate)
<P>Two core subjects
<P><I>MA 842 Coding for Reliable Communications, MA 843 Cryptography
and Security.</I>
<P>Two electives from the following list
<P><I>MA 844 Algebraic Coding and Decoding, CS 861 Introduction
to Data Communications,</I>
<BR><I>MA 846 Information Theory for Secure Communications, MA 847
Smartcard Cryptosystems.</I>
<BR>
<BR><U>MASTER OF APPLIED SCIENCE (by COURSEWORK) in INFORMATION
SECURITY</U>
<P>48 CREDIT POINTS = 4 12 CREDIT POINT SUBJECTS =
<BR>1 YEAR PART TIME = 1 SEMESTER FULL TIME
<BR>(after completing the Graduate Diploma)
<P>Two core subjects
<P><I>MA 845 Advanced Topics in Cryptography, MA 848 Project
I </I>
<P>Two electives from the following list
<P><I>MA 844 Algebraic Coding and Decoding, MA 846 Information Theory
for Secure Communications, MA 847 Smartcard
Cryptosystems,
CS 830 Introduction to Databases,</I>
<BR><I>CS 447 Secure Electronic Commerce, MA 849 Project II</I>
<P> <A
HREF="http://www.ma.rmit.edu.au/kepler/pgrad/InfoSec.html">http://www.ma.rmit.edu.au/kepler/pgrad/InfoSec.html</A>
<BR><U></U>
<BR><U></U> </HTML>
==============7C54AA42338E11BBBDDD8780==
------------------------------
From: Dave Knapp <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Wed, 08 Dec 1999 03:40:09 GMT
On Tue, 7 Dec 1999 15:05:34 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>You don't seem to see the problem. Detecting single photons is not
>really a big problem.
>
>Detecting them in such a way that no bias in introduced into the
>(supposedly) random quantum behaviour *is*.
How about an upper limit on bias? That can quite easily be arranged
by making the energy of the photon sufficiently large.
And, using the Mossbauer effect, I can reduce any residual bias
further.
My back-of-the-envelope guess is that you could quite easily reduce
any bias from a quantum-mechanical RNG to a part in 1e15 or so; that
is certainly well beyond the capability of any cryptanalysis to
detect. Of course, in not explaining that further I am (vainly,
perhaps) hoping that your ignorance of statistics isn't as gross as
your ignorance of physics.
Maybe you should learn a little bit of physics before pronouncing on
it as if you were an expert.
-- Dave
------------------------------
From: Dave Knapp <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Wed, 08 Dec 1999 03:41:59 GMT
On Tue, 7 Dec 1999 15:17:41 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>The idea that false detections will be random is not necessarily
>correct. Cosmic ray frequencies are influenced by sunspot activity,
>for example.
Just for the record: the above is nonsense. Just Plain Wrong.
-- Dave
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Wed, 08 Dec 1999 04:12:18 GMT
Sander Vesik wrote:
> Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> > Sander Vesik wrote:
> >> For starter, consider Pearl Habor.
> > What about Pearl Harbor?
> Japanese bombers do not get intercepted (while it is known that these
> will, in fact be flying in to attack Pearl Harbor) as the US
> considered all and any losses it would take (took) as inferior to
> admitting that it could crack Japanese crypto.
That is not at all true. Where did you get such a notion?
Certainly not from the Congressional investigation into Pearl.
> >> You are also forgetting that 'law enforcment' backdoors in banking
> >> software have been criminally exploited before.
> > What "law enforcement" backdoors in banking software?
> Regular backdoors allowing unauthorised parties to gain access,
> designed to be only usable by law enforcement (but prooved to be
> usuable by others).
If you're talking abut the key escrow proposed for the so-called
Clipper initiative, that was never put into practice. If you're
talking about something else, please be more specific.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Wed, 08 Dec 1999 04:13:43 GMT
karl malbrain wrote:
> The point, you idiot, is that both B-1B's and airlines use TOILET SEATS!!!
> Why not the same ones? Karl M
Passenger planes allocate more space. Look inside a bomber some time.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Wed, 08 Dec 1999 04:18:18 GMT
"SCOTT19U.ZIP_GUY" wrote:
> One way would be to rule keys that where obtained through other
> means. Example if your toture someone into giving a key. The key
> could be tested.
But, the key can be tested even with one-on-one encryption.
I don't think there *is* a practical defense against such an
attack, other than making sure that the key is not known (in
the sense that they could divulge it) to the legitimate
communicants.
> Two depending on the cipher used whole classes of the key itself
> may be eliminated from the search space.
That's what I don't see.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Wed, 08 Dec 1999 04:20:35 GMT
Tim Tyler wrote:
> Really?
Yes.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Paradise shills??
Date: Wed, 08 Dec 1999 04:26:54 GMT
Daniel Hutchings wrote:
> What I don't understand is, why use a pseudo-random number generator
> at all? You can buy physical devices that use quantum effects to
> generate random numbers, and baby it just doesn't get any more random
> than that.
If you do that, you need to communicate the entire key stream
to the other party; how are you going to do that securely?
With a PRNG, both parties need merely know a handful of bits
worth of parameters for the PRNG, and a seed that can be
prearranged or, sometimes, sent with the ciphertext.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Encrypting numbers? (Thanks all!)
Date: Wed, 08 Dec 1999 04:30:07 GMT
Michael Groh wrote:
> I hadn't considered that this makes the crypanalysis job much harder
> as well!
Actually, spelling out numbers usually aids cryptanalysis.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Frequency results of twofish and serpent.
Date: Wed, 08 Dec 1999 04:43:53 GMT
albert wrote:
> I'm shocked ... on how evenly distributed the values are. ...
> this is not the most scientific of test methods, ...
The significance of the data is not evident in the form in which
you presented it: the larger the sample, the more uniform one
would expect the distribution to be (in relative terms). Why not
compute how probable it is that a sample of that size would be
less flat, on the hypothesis of a uniform random distribution?
It could well be that the observed distribution is much *flatter*
than would be expected at random..
------------------------------
** 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
******************************
