Cryptography-Digest Digest #174, Volume #11 Mon, 21 Feb 00 11:13:01 EST
Contents:
Re: US secret agents work at Microsoft claims French intelligence report
([EMAIL PROTECTED])
Re: Who is using ECC? ([EMAIL PROTECTED])
Re: NIST publishes AES source code on web (Mok-Kong Shen)
Re: Which compression is best? (Runu Knips)
Re: Who is using ECC? (DJohn37050)
Re: NSA Linux and the GPL (Paul Crowley)
Re: Does the NSA have ALL Possible PGP keys? ("J.P. van Bolhuis")
Re: NIST publishes AES source code on web ("Brian Gladman")
Re: Which compression is best? (Runu Knips)
Re: Beginner Help ? (Alex MacPherson)
Re: I will bring PGP to the masses h15 ("Douglas A. Gwyn")
Re: EOF in cipher??? (Runu Knips)
Re: EOF in cipher??? ("Douglas A. Gwyn")
Re: EOF in cipher??? (Runu Knips)
Re: Processor speeds. ("Douglas A. Gwyn")
Re: EOF in cipher??? (Runu Knips)
Re: Beginner Help ? ("Norman Little")
Re: NIST publishes AES source code on web ("Douglas A. Gwyn")
Re: Does the NSA have ALL Possible PGP keys? (Bobo)
Re: Implementation of Crypto on DSP ([EMAIL PROTECTED])
Re: EOF in cipher??? (Runu Knips)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: US secret agents work at Microsoft claims French intelligence report
Date: Mon, 21 Feb 2000 11:04:45 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Dave Hazelwood) wrote:
> An intelligence report out of France has accused US secret agents of
> collaborating with computer giant Microsoft in developing a software
> that would allow Washington to spy on communications around the world.
Interesting news. On the other hand, I wonder if Microsoft ever would
need the help of secret agents to make their products insecure... I've
always thought they can do it on their own. ;-)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Who is using ECC?
Date: Mon, 21 Feb 2000 11:23:14 GMT
In article <[EMAIL PROTECTED]>,
JCA <[EMAIL PROTECTED]> wrote:
>
> I'd be interested to learn who is using ECC. I am aware that it is
> far less well-known than RSA,
Apple Inc. is claimed to use it for their signing implementation in Mac
OS 9. But contrary to other beliefs, they don't use it for crypto (they
use RC2 for keychain encryption and a weak algorithm called ASC for file
encryption).
Best regards,
Erich Steinmann
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES source code on web
Date: Mon, 21 Feb 2000 13:59:24 +0100
Douglas A. Gwyn schrieb:
>
> Mok-Kong Shen wrote:
> > ... the US lobbyed to have the crypto clauses put in.
> > (A high official came to Bonn for that.)
>
> Note that the US Congress had immediately prior to that told the
> US Executive branch that such controls, especially key escrow
> provisions, were not the will of the People of the US. But
> this Administration has the longstanding habit of all Liberal
> Democrats of believing that it knows what is best for others and
> will keep trying to get its way regardless of the absence of a
> mandate to do so.
I realize that what I am now writing is fairly off-topic, but
perhaps an exception could occassionally be indulged (at least
in the sense that an exception of 'knowingly' and officially
'voluntarily' giving 128/256 bit strong crypto into the hands
of terrorists is considered o.k. -- that such secrets could not
be kept in practice from being obtained by them is not the point
here).
It seems that plenty of non-US subjects have the feeling that
in the US system the president has too much power (his vetos)
in comparison to European systems. But of course in Europe the
problem is only shifted to another level, namely there is the
question of what if the elected members of the parliaments make
wrong decisions due to lobbying or, worse, even corruptions.
For a concrete case, as far as I am aware, there was considerable
sentiment among the people at the time before the decision about
Euro that their opinions were not properly represented in the
parliaments and that they were not 'asked' for their opinions for
such a very important issue. But Euro was introduced nonetheless.
Sometime ago I read a newspaper comment saying that those experts
[big names in their profession] that once euphorically advocated
Euro have become remarkably silent. (Incidentally, this also
demonstrates that even the best-known academics are human and
could err. Thus it may not be wise to always believe what the
crypto-popes say without one's own reflections.)
A democratic system can, like everything created by humans, never
be perfect. (Some of the recent news from the political platform
in west Europe should convince the most hard-necked disbeliever
of this.) But the internet does contribute something (how much
is of course an issue of subjectivity) to rendering it better.
I suppose it is not entirely wrong to say that discussions in
the internet have helped to stop the nonsense of key-escrow.
I personally have the feeling that the crypto groups and mailing
lists have non-trivially contributed to the present relaxation
of EAR and perhaps also later to a revision of the crypto clauses
of the Wassenaar Agreement. (Besides international groups like
the one of ours there are also fairly active national groups, e.g.
in Germany de.comp.security.)
M. K. Shen
===========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
Date: Mon, 21 Feb 2000 13:57:25 +0100
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Which compression is best?
"SCOTT19U.ZIP_GUY" schrieb:
>
> In article <[EMAIL PROTECTED]>, Runu Knips
><[EMAIL PROTECTED]> wrote:
> >Tim Tyler schrieb:
> >> Runu Knips <[EMAIL PROTECTED]> wrote:
> >> : This is how ALL compressors work. No matter if simple RLE or
> >> : Huffman or ZiffDavis or whatever. Their output always follows rules.
> >> Their "output always follows rules" in the sense that it is
> >> deterministically derived from the input text.
> >> : [...]
> >> That does *not* mean you can write a program that identifies compressed
> >> files as such.
> >
> >Well okay, I in fact didn't tried this in practice. For example, I know
> >that Huffman has to first dump the huffman tree, and then the huffman
> >codes follow. And because the input is not ideal random data (where each
> >character appears as often as the other), you will not get a balanced
> >tree (which would make compression by Huffman impossible anyway) as the
> >huffman tree, therefore some codes are not possible.
> >
> >An easy example is the huffman alphabet for a file which contain 70%
> >nuls and 10% space plus 10% A plus 10% B (just to make calculation
> >easy). The resulting alphabet would be:
> >
> >NUL = 0
> >SPACE = 100
> >A = 101
> >B = 110
>
> You obviously have a piss poor understanding of even basic huffman
> coding. No wonder your totally lost in the disscussion with Tim. Please
> try to learn something about basic huffman coding before you start to
> generalize about stuff of which you seem to have no idea.
> This example you give above where a file contains only 4 symbols
> would not have the tree you show above.
> True Null could equal 0
> and Space could equal 100
> and A could equal 101
> but then B would have to be 11
ARGL !!!
You're right.
> Sorry but I assume if these minor points are over your head
> you will not be able to understand Tim
I haven't heared about 1:1/bijective compressors before
anyway, this is a totally new idea to me.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Who is using ECC?
Date: 21 Feb 2000 13:39:10 GMT
See www.certicom.com for the list of partners using ECC.
Don Johnson
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: NSA Linux and the GPL
Date: 21 Feb 2000 07:51:09 -0000
"Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
> As another poster hinted, no matter how much the security of Linux
> is beefed up, it will not become Multi-Level Secure, and hence its
> security will never be relied upon to act as a barrier between the
> public and classified information.
Of course, if you're not the NSA this may not be such a disadvantage:
Ross Anderson has made some very convincing criticisms of MLS when
applied outside a military context.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: "J.P. van Bolhuis" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Mon, 21 Feb 2000 15:02:17 +0100
James Felling wrote:
> tiwolf wrote:
>
> > No I am saying that once man thought the earth was the center of the solar
> > system, now time, thought , research and a good amount of money show us
> > differently. I am also not saying that all codes are broken, I am only
> > saying that the code that are not yet broke will in time be broken.
>
> Why do you claim that "any code can be broken"? I can accept the statement
> given a code X there exists no way of determining whether or not a break can or
> will exist at some point in the future. However, I do not accept the statement
> that all presently existing codes must therefore possess a break.( By break I
> mean an attack against it that is faster than brute force)
>
> > The only
> > code that is will never be broke is the code that man never develops.
>
> or one that a break of is equivalent to solving an unsolvable (by any means
> other than trying all the possibilities) problem
>
Or the code that isn't meant to be reversible (these also come in varieties and
qualities).
A trivial solution would be the mapping of [any character] => [m]
Mathematically it is proven (AFAIK of course) that there can be codes that cannot be
broken. Unfortunately the group of coding mechanisms for which it has been proven,
also destroy information.
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES source code on web
Date: Mon, 21 Feb 2000 14:31:06 -0000
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Brian Gladman wrote:
> >
> > The Wassenaar Arrangement (WA) is no more than an informal agreement and
> > this means that the extent to which national laws implement its
provisions
> > is highly variable since there is a legal obligation on any of its
> > participants to do anything.
>
> What is your definition of 'informal' where high government offcials
> from ministries signed for their respective countries? It is known
> that the agreement has to be ratified. But is that the 'characteristic'
> that led you to consider that the agreement is 'informal'? (Even
> a peace treaty ending a war needs ratification, if I don't err.)
>
> >
> > The US has generally gone way beyond what is required and recent changes
> > have simply bought US regulations somewhat closer to its provisions.
> >
> > Many other countries do not implement any restrictions on commercial
> > cryptographic products because the WA does not require this. In
practice
> > only a few countries now intepret the crypto controls in Wassenaar as
having
> > any impact on such products. There are token restrictions on export to
> > 'naughty countries' but everyone involved knows that these are of little
> > practical value.
>
> Could you please cite the text of Wassenaar Agreement that exempts
> 'commercial products' from its crypto restrictions?
See my paper listed at:
http://www.brian.gladman.btinternet.co.uk/papers/index.html
Most people who comment on the WA don't seem to have read it. I have and in
detail.
> Your sentence 'The US has generally gone way beyond what is required'
> is indeed interesting. The US seems to do that in one AND also the
> other direction. Previously it posed in its own territories
> crypto restrictions much more severe than what the other countries
> were ready to pose. Now that there are, after much lobbying, finally
> crypto clauses of the Wassenaar Agreement (US was the main pushing
> force in that!), the US, for reasons (in my view) not very apparent
> (or convincing) to the outside world, suddenly wanted to relax the
> restrictions and, according to an official document quoted in this
> thread, even now permits strong crypto of 128 and 256 key bits
> freely accessible from terrorist countries, which is certainly
> contrary to the spirit of the Wassenaar Agreement.
Who said anything about 'spirirt' - in crypto the name of the WA is mostly
used for other purposes that have nothing to do with the aims of the WA
itself.
The WA is not intended to be used to prevent bona fide commerical
transactions and 99.9% of crypto sales fall in this category.
[snip]
Brian Gladman
------------------------------
Date: Mon, 21 Feb 2000 16:03:34 +0100
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Which compression is best?
Michael Wojcik schrieb:
> In article <[EMAIL PROTECTED]>, Runu Knips
><[EMAIL PROTECTED]> writes:
> [...]
As I already said, I didn't knowed about 1-1 compression.
> > Well okay, I in fact didn't tried this in practice. For example, I know
> > that Huffman has to first dump the huffman tree, and then the huffman
> > codes follow.
>
> That's a typical protocol for the application of Huffman's compressor,
> but it is by no means a rule. [...]
I know, that was a simplification.
------------------------------
From: Alex MacPherson <[EMAIL PROTECTED]>
Subject: Re: Beginner Help ?
Date: Mon, 21 Feb 2000 10:13:56 -0500
Norman Little wrote:
> Anyway, what I would like to
> know, is if anyone can help me how to split my plaintext up into 8-bit
> blocks or whatever, or even if there is a way for me to demonstrate this by
> dividing the message into characters.....
Norman,
There is a simple way to do this in JAVA in your plaintext is of the class
java.lang.String. The method getBytes() returns an array of bytes for the
String. This is one method of dividing your plaintext into 8-bit blocks.
--
Alex MacPherson
Department of Mathematics and Computer Science
Royal Military College of Canada
email: [EMAIL PROTECTED]
voice: 613-541-6000 X6450
ICQ: 55131390
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: I will bring PGP to the masses h15
Date: Mon, 21 Feb 2000 15:25:30 GMT
PGP_for_ALL wrote:
> I will bring PGP to the masses
The only way the typical PC user is going to use PGP is for it to
be the *default* mode of his e-mail interface *as bundled* with his
computer or ISP package when he purchases it.
------------------------------
Date: Mon, 21 Feb 2000 16:30:05 +0100
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
"Douglas A. Gwyn" schrieb:
>
> Runu Knips wrote:
> > Unfortunately, the above code will run on many systems without
> > problems until fp is a binary file which happends to contain
> > the code 0xff, which is equal to (signed char)-1 (on machines
> > with 8 bits for a character).
>
> Wrong again! When getc reads an FFh byte, it returns the
> *int* value 0xFF, which is *never* equal to EOF.
Which is equal to EOF if interpreted as a signed char, because:
a) (unsigned char)(signed char)(-1) == 0xff
b) (int)(signed char)0xff == (int)(-1)
Got it ?
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Mon, 21 Feb 2000 15:33:15 GMT
Mok-Kong Shen wrote:
> ... Imagine the case I am going to have a major surgical operation
> and I hear the surgeons disputing about which knifes should
> properly be used!
If that were an Internet newsgroup dispute, you would be a fool
to think that it was an argument among surgeons. It would be an
argument among perhaps a surgeon or two (who would agree on the
main points) and a bunch of people who would not be allowed
anywhere near a real operating room (except as patients).
------------------------------
Date: Mon, 21 Feb 2000 16:34:09 +0100
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
David Hopwood schrieb:
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> "Trevor Jackson, III" wrote:
> > Mok-Kong Shen wrote:
> > > Stephen Houchen wrote:
> > >
> > > > If you're programming in C, open the file as "binary" (mode "rb", for
> > > > example).
> > >
> > > I am ignorant of what the C standard specifies. Question: Does
> > > 'binary' require the file to be multiple of words or just any multiple
> > > of bytes will do? Thanks.
>
> The latter.
>
> > Neither. The elements written to files are characters.
> > Sometimes (usually) that means bytes.
>
> The elements written to files in binary mode are required to be able
> to represent the values 0..255,
The 'elements', i.e. 'char', in binary mode are required to represent
0..UCHAR_MAX, which is at least 2**7-1 == 127.
> and are not required to be able to be
> able to represent any other values. In that sense they are (always)
> 8-bit bytes.
No, that depends upon the actual architecture.
But from a practical point of view, you're right. Machines where
bytes have 7, 9 or 10 bits became very seldom today.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Processor speeds.
Date: Mon, 21 Feb 2000 15:37:16 GMT
Mok-Kong Shen wrote:
> I am convinced that the Cray type is out even though I am personally
> acquainted with persons who are still 'fans' for that for reasons
> comprehensible (as well as uncomprehensible) for me.
Re-read my previous posting. Supercomputers, like PCs, evolve.
Some problems simply do not benefit much from massively parallel
processing. And some problems that are highly parallelizable
also require coordination among the processing units that is
hard or impossible to achieve effectively with networked PCs.
So networked PCs cannot totally replace true supercomputing.
------------------------------
Date: Mon, 21 Feb 2000 16:43:02 +0100
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
"Douglas A. Gwyn" schrieb:
>
> Runu Knips wrote:
> > ... A character value, however, is
> > the smallest type which has at least 7 bit.
>
> No, there have to be at least 8 bits in a char.
Okay, this might have changed, but at least when I've learned
C (many years ago), I read in my K&R CHAR_BIT (number of bits
in a character, defined in limits.h) must be at least 7 bit.
> Char is the smallest unit of addressable storage at the
> level of C source code, but the implementation can make it
> larger than logically necessary so long as all requirements
> are met. Because there has been no standard way to designate
> an object type smaller than char in C, char is almost always
> 8 bits (unless the architecture is one of the antique ones
> that has a non-power-of-two word size)
Errm.... if I understand you correctly here, you agree with
me that it might be sometimes 7, 9, or 10 bits ? Of course
not on modern architectures ! But on some old ones.
> in order to support
> many C programmer's expectations that they will be able to
> pick off octets by aliasing objects to arrays of char.
> In principle, a conforming C implementation could make
> char have 16 bits, but I am unaware of any that have done so.
------------------------------
From: "Norman Little" <[EMAIL PROTECTED]>
Subject: Re: Beginner Help ?
Date: Mon, 21 Feb 2000 15:38:09 -0000
Hi,
Sorry if I was unclear....
What I meant was that I am using JAVA, and the message is coming in from a
textfield into a String. Up to this point, I have been taking each
character and performing the substitution or transposition technique on it
then putting it into another string.
Where my confusion lies is that the simplified DES algorithm in the book I
am reading talks about dividing the message into 8-bit chunks and then
performing the IP, fk1, SW, fk2, IP-1 operations on it. The book describes
these functions as manipulations of the bits, so I was wondering if there is
a way for me to demonstrate the effects of the algorithm without dividing
into 8-bit chunks...or is there a way in JAVA to do this correctly ?
thanks
Norman
> Your question is somewhat puzzling.
>
> In order to divide your plaintext into blocks of eight bits, it first
> has to be composed of bits. If you represent the characters of your
> message, assuming it is a text message, using either ASCII or EBCDIC,
> the result will already be in groups of eight bits, since that is the
> size of a character in those codes (although ASCII can also be thought
> of as a 7-bit code).
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES source code on web
Date: Mon, 21 Feb 2000 15:45:32 GMT
Mok-Kong Shen wrote:
> ... in principle (theory) anything that limits/reduces the
> capabilities of the bad guys is good.
That theory is bogus, although it has a surface appeal if one
doesn't think about it. It's easier to see what is wrong if
you apply it to a non-emotional issue: Bad Guys presumably use
pencils; we should regulate the use of pencils to hamper the
Bad Guys.
> The situation is somewhat different in the case of, say,
> drug control. Here there is meterials involved and the
> authorities can exercise control and achieve certain real
> efficicies, even though it is apparent that one can never
> 'absolutely' solve the problem of drugs before the police
> recruits at least one tenths of the population to be its
> officiers.
The so-called "War on Drugs" has led to many abuses without
significantly improving the drug situation. The drug problem
is a social and psychological problem, not something that can
be solved by any amount of law enforcement. The US should
know better, from its previous dalliance with nationwide
alcohol prohibition, but people don't learn from history and
they seek easy solutions to problems that don't have easy
solutions.
This seems to have strayed from relevance to cryptology,
although there are still echos of a connection.
------------------------------
From: Bobo <[EMAIL PROTECTED]>
Crossposted-To: misc.survivalism,comp.security.pgp.discuss
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Mon, 21 Feb 2000 08:46:49 -0700
Reply-To: [EMAIL PROTECTED]
On Mon, 21 Feb 2000 03:59:59 GMT, [EMAIL PROTECTED] (John
Savard) said:
>God, being perfect, has correct knowlege about mathematics. Thus, He
>knows all the properties of all the integers. And He also knows the
>truth about "the largest integer": there is no such thing. Anyone who
>thinks he knows what the largest integer is is a fool, and God is no
>fool.
>
>However, He does know all the transfinite numbers, and whether the
>Continuum Hypothesis is true or not. And there is at least one body of
>opinion concerning the transfinite numbers that does postulate a
>largest transfinite number, denoted by a capital omega - rather
>appropriately. So perhaps there can be a largest _number_, if one
>leaves the real line to include the transfinites.
Well, I would postulate that an infinite being can have direct knowledge of an
infinite amount of numbers. An infinite being with infinite knowledge knows
Pi to all of it's decimal places, for instance. An infinite being could
probably divide by zero with no problems whatsoever. :-)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Implementation of Crypto on DSP
Date: Mon, 21 Feb 2000 15:43:56 GMT
I am working on a network crypto hardware card, and I would like to know
if there are any assembler libs ( 3DES, DH etc) for say Anolog Dev or TI
DSP .
Do I need a 32 bit integer DSP or will 16 bit be ok ( I guess that
depends on the math libs). Also do I need any FP h/w on the DSP, since
all crypto (ciphers, dh etc) is integer arithmetic.
If you know of a good H/W random no generator chip, that would also be
great ( johnson noise device etc).
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 21 Feb 2000 16:50:19 +0100
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Joseph Ashwood schrieb:
> I realize that I'm rather late to this long thread, but I
> have noticed that particularly on the Windows sometimes eof
> is reported incorrectly. The following is the rough outline
> of what I typically do to correct the problem.
>
> Open file as binary (as has been suggested use rb, since
> this is for reading)
> fseek to the end of the file
> endingLocation = ftell
> fseek to the beginning of the file
> after each read compare the current ftell to endingLocation,
> if they are the same you've reached true end of file
Cool trick.
No, really.
The stdio on Windows behaved that ugly, that I often
finally replaced it with some direct API calls. If
the program crashes, some already fclose()'d files
will have zero content (especially bad if they contain
some debugging output !!!) and so on.
------------------------------
** 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
******************************
