Cryptography-Digest Digest #181, Volume #11 Tue, 22 Feb 00 12:13:01 EST
Contents:
Re: How Useful is Encryption as Long as NSA Exists? ([EMAIL PROTECTED])
The solution is Open Source! ([EMAIL PROTECTED])
Re: NIST publishes AES source code on web (Sander Vesik)
Re: EOF in cipher??? (Vernon Schryver)
Re: US secret agents work at Microsoft claims French intelligence report
([EMAIL PROTECTED])
Re: EOF in cipher??? ("Douglas A. Gwyn")
Re: EOF in cipher??? ("Douglas A. Gwyn")
Re: EOF in cipher??? ("Douglas A. Gwyn")
Re: How Useful is Encryption as Long as NSA Exists? ([EMAIL PROTECTED])
Re: Using virtually any cipher as public key system? (John Savard)
Re: EOF in cipher??? ("Douglas A. Gwyn")
Re: Does the NSA have ALL Possible PGP keys? ("Douglas A. Gwyn")
Re: Implementation of Crypto on DSP ("Douglas A. Gwyn")
Re: NIST publishes AES source code on web ("Douglas A. Gwyn")
Re: EOF in cipher??? (Runu Knips)
Re: EOF in cipher??? (Runu Knips)
Re: EOF in cipher??? (Runu Knips)
Re: Implementation of Crypto on DSP (Peter Gutmann)
Re: EOF in cipher??? (JPeschel)
Re: How Useful is Encryption as Long as NSA Exists? ("Douglas A. Gwyn")
Re: UK publishes 'impossible' decryption law (zapzing)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How Useful is Encryption as Long as NSA Exists?
Date: Tue, 22 Feb 2000 15:23:46 GMT
In article <88t1rf$6hl$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> As I mentioned earlier in this forum it is
> already possible to set up quantum encryption
> via a fiber optic network and this system so
> far appears immune to eavesdropping.
You still have to use a keyboard to type in your message, right?
No system is immune to eavesdropping. Even if you can't eavesdrop the
channel itself, it's not too difficult to eavesdrop the endpoints.
-Erik Runeson
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: The solution is Open Source!
Date: Tue, 22 Feb 2000 15:29:45 GMT
In article <88s99s$lhu$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
How can we be sure our encryption software has no backdoor?
The answer, of course is Open Source. There are several free open source
encryption packages available, e.g. the java package by www.cryptix.org.
The source code for this is available, so anyone with a basic
understanding of programming and math can check the code to make sure
there are no secret backdoors or key escrow systems.
It's free, and you yourself can ensure it's safe! Goodnight NSA...
-Erik Runeson
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Sander Vesik <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES source code on web
Date: 22 Feb 2000 15:41:18 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> Mok-Kong Shen wrote:
[snip]
>> Making strong crypto of 128/256 bits (entirely) freely available
>> to the terrorist countries does not only contradict its previous
>> wishes (while lobbying) but also evidently goes in a direction
>> diametrically opposite to the aim and spirit of Wassenaar as a whole
>> (crypto is only a part of the issues contained in the Agreement).
>> Why it does this is not yet very clear (in the sense of understandable
>> proofs) to me.
> The politics may not be clear, but the technical point has always
> been obvious that such restrictions do not significantly impede
> the Bad Guys (who can tunnel in their own strong crypto), while
> they do significantly impair the freedom and privacy of the Good
> Guys. Perhaps there is a feeling among the decision makers that
> the ploy of removing more and more freedom in the name of "law
> enforcement" is not fooling so many citizens these days.
Not to mention that it makes it just as easy for the "nonbad"
groups inside bad countries to have the crypto, which is a good thing.
--
Sander
There is no love, no good, no happiness and no future -
these are all just illusions.
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: EOF in cipher???
Date: 21 Feb 2000 10:58:50 -0700
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> 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).
It's worse than that. The Endless September that started in about
1989 was characterized by a permanent flood of people who acted
like sophomores. They knew everything, but they also cared about
the facts. You could get through to them. Some of them would even
look for facts on their own, doing crazy things such as not only
buying books on C and C++, but actually reading them.
A few years ago, the Endless September ended, and the Endless
Breaker-Breaker-19 CB Radio session began. The CB Radio netnews
enthusiasts don't care about facts. They are like cartoons of the
caricature of the know-it-all postman on the TV program "Cheers." No
matter how often they are corrected, they will continue to blabber their
silly nonsense. They are confused, insulted, and respond with insults if
you try to correct their nonsense, because the point of their articles is
not to convey facts, but their images of themselves as experts. It makes
as much sense to discuss C types, compression, or encryption with them as
with patrons in a typical bar a few minutes before closing time.
Sci.crypt, like most newsgroups today, has a bunch of frequent
contributors who are members of the CB Radio legion. You would do
those of us who do care about facts a favor if you would add them
to your killfile. That would save us the trouble of having to
manually filter your hopeless tilting at their windmilling foolishness.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: US secret agents work at Microsoft claims French intelligence report
Date: Tue, 22 Feb 2000 15:45:01 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Dave Hazelwood) wrote:
> According to the report, "it would seem that the creation of Microsoft
> was largely supported, not least financially, by the NSA, and that IBM
> was made to accept the (Microsoft) MS-DOS operating system by the same
> administration".
>
> It also said that the Pentagon was Microsoft's biggest client in the
> world.
And JFK was probably murdered because he was opposed to this devilish
plot!
(someone's been watching too much X-Files recently...)
-Erik Runeson
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Tue, 22 Feb 2000 14:47:54 GMT
Runu Knips wrote:
> "Douglas A. Gwyn" schrieb:
> 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_BIT and <limits.h> didn't exist for 1st Ed. of K&R;
when they first were introduced, there was already a
requirement that CHAR_BIT be at least 8. If K&R 2nd Ed.
says otherwise (which I doubt), then it is wrong.
> 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.
No implementation of C that conforms to the standard can have
7-bit chars. Anything from 8 on up is allowed, if all other
requirements are met.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Tue, 22 Feb 2000 14:52:02 GMT
Runu Knips wrote:
> I do not think that many of the people which argued here aren't
> experienced in programming. Too, as long as you just write (for
> text files):
> _____________________________________
> int ch;
> FILE *f;
>
> f = fopen (name, "r");
> while ((ch = getc (f)) != EOF) {
> ...
> }
> _____________________________________
> you're safe according to (AFAIK) ANYONE which posted here.
No! In fact, you have duplicated the error that started this
thread.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Tue, 22 Feb 2000 15:01:37 GMT
Runu Knips wrote:
> "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 ?
Oh, I understand what you're saying just fine, but you don't
understand what I'm saying. Reading a 0xFF byte from a binary
file does *not* cause spurious detection of EOF (assumed to
be defined as -1) in the case to which you originally responded:
> "Trevor Jackson, III" schrieb:
> > Mok-Kong Shen wrote:
> > > To be sure that I didn't misunderstand, I like to ask whether the
> > > code (from KR):
> > > while ((C = getc(fp)) != EOF)
> > > .........
> > > needs to be modified or using rb is sufficient for taking care of
> > > the presence of any bit combinations in the file. Thanks.
> > The issue is the type of the variable C. To operate correctly it must
> > be an int not a char.
> 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).
The value of the variable C declared as an int (as it was in K&R
and in Jackson's response) when 0xFF is read from a binary stream
will be 0xFF, which will compare unequal to EOF (defined as the
integer constant -1).
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How Useful is Encryption as Long as NSA Exists?
Date: Tue, 22 Feb 2000 16:00:37 GMT
> > I do not fully understand the implications of the regularity we discovered
> > but it certainly makes one wonder about the possibility that a backdoor
> > exists.
>
> It sounds more like a programming mistake on MS's part. If it was a
> deliberate backdoor, you'd expect it to be rather better hidden (such as,
> having a guessable salt based on the something obscure in the ciphertext, or
> better yet, hiding the key somewhere in the ciphertext in an obfuscated
> format). Besides, unless you were going through a huge number of
good point, but you also have to consider that it's an urgent interest of
an organization like the NSA to make a possible backdoor *look like* it
only was a programming error. This would also be in the interest of the
co-operatinh Microsoft company, because a little bug looks better than an
intentionally produced security hole...
Best regards,
Erich Steinmann
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Using virtually any cipher as public key system?
Date: Tue, 22 Feb 2000 09:14:31 GMT
Anton Stiglic <[EMAIL PROTECTED]> wrote, in part:
>I think you were just confusing the terms you were using. In any case,
>I don't see why anyone would need public key encryption whitout any
>public key scheme, it does not make much sens.... something has to
>be public if the two participants don't have any way to personaly
>communicate in a secure way.
What does make sense, even if it is not possible to achieve in
practice, is what the original post expressed a desire for: a public
key scheme (yes) that is "without", say, modular exponentiation and
stuff like that. A public key scheme that can use, as its basis,
either existing secret key ciphers or hash functions as primitives, or
at least be built from primitives similar to those used in block
ciphers and hash functions. For the public key part itself, not for
the bulk encryption after the key is exchanged.
The advantage here is twofold: speeding up the public-key portion of
the cipher system, and an increase of security, if one can arbitrarily
pile up complications the way one can in designing a symmetric cipher.
There's the Merkle puzzle protocol, but although it "sort of" meets
the condition, it is not secure, and doesn't produce the kind of
benefits aimed at.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Tue, 22 Feb 2000 15:05:06 GMT
Runu Knips wrote:
> The 'elements', i.e. 'char', in binary mode are required to represent
> 0..UCHAR_MAX, which is at least 2**7-1 == 127.
Wrong yet again. The specification of UCHAR_MAX has always
required that it be at least 255.
------------------------------
Crossposted-To: misc.survivalism,comp.security.pgp.discuss
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Tue, 22 Feb 2000 15:11:35 GMT
Bobo wrote:
> ... [EMAIL PROTECTED] (John Savard) said:
> >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.
I missed that, but it's wrong on at least two counts:
(1) The continuum hypothesis has been proven to be independent;
either it or its negation can be added to the other axioms and
the resulting system will be just as consistent as without it.
(2) Omega normally denotes Chaitin's number. If you buy into
Cantor's transfinite numbers, then it can be proven that there
is no largest transfinite number. About the only exception
would be Brouwer's school of intuitionism, for which there is
at most one transfinite number.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Implementation of Crypto on DSP
Date: Tue, 22 Feb 2000 15:18:56 GMT
[EMAIL PROTECTED] wrote:
> 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 .
You don't really need to use assembly language on the TI TMS320C6x
DSP; its C compiler does a very good job of optimizing to use
multiple processing elements. (I have no experience with AD DSPs.)
> 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.
It depends on the particular algorithm. The main thing wider
integer support gives you is the ability to process more bit
streams in parallel, which improves overall throughput when you
can take advantage of it.
For enciphering/deciphering, a FP unit is essentially useless, but
it might be helpful for other applications on the DSP (if any).
> If you know of a good H/W random no generator chip, that would also be
> great ( johnson noise device etc).
Why not just use the Motorola AIM? It has all that, including
development libraries specifically geared to crypto, and is Type I
approved by NSA, yet (apparently) freely exportable.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES source code on web
Date: Tue, 22 Feb 2000 15:27:58 GMT
Paul Koning wrote:
> The claim of "on his own initiative" has certainly been made
> before; I wonder how many people find it convincing.
Some people won't be convinced by any amount of evidence,
but the Agency itself appears to believe that, according
to an internal review that had no cause to be misleading.
------------------------------
Date: Tue, 22 Feb 2000 17:27:18 +0100
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
"Douglas A. Gwyn" schrieb:
> No! In fact, you have duplicated the error that started this
> thread.
Wrong, I wrote about text files, so there is no error.
------------------------------
Date: Tue, 22 Feb 2000 17:29:13 +0100
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
"Douglas A. Gwyn" schrieb:
>
> Runu Knips wrote:
> > The 'elements', i.e. 'char', in binary mode are required to represent
> > 0..UCHAR_MAX, which is at least 2**7-1 == 127.
>
> Wrong yet again. The specification of UCHAR_MAX has always
> required that it be at least 255.
How long should this discussion continue ? CHAR_BIT is AT LEAST 7,
so UCHAR_MAX is AT LEAST 127 != 255. Thats what my K&R says.
------------------------------
Date: Tue, 22 Feb 2000 17:30:41 +0100
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
"Douglas A. Gwyn" schrieb:
>
> Runu Knips wrote:
> > "Douglas A. Gwyn" schrieb:
> > 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_BIT and <limits.h> didn't exist for 1st Ed. of K&R;
Of course, my K&R is a later edition AFTER the ISO standard
was written.
> when they first were introduced, there was already a
> requirement that CHAR_BIT be at least 8. If K&R 2nd Ed.
> says otherwise (which I doubt), then it is wrong.
> > 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.
>
> No implementation of C that conforms to the standard can have
> 7-bit chars. Anything from 8 on up is allowed, if all other
> requirements are met.
Okay, I give up. If you believe this, then let us agree
to disagree.
------------------------------
From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: Implementation of Crypto on DSP
Date: 22 Feb 2000 16:13:54 GMT
[EMAIL PROTECTED] writes:
>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 .
You're in for a lot of fun in researching the best way to do this
(availability of parts, cost, performance, etc etc). In short unless you're
doing it as a hobby (where cost is no object) or you have a lot of money to
invest in it, it's very difficult to make it financially worthwhile. If all
you're looking for is an IPSEC accelerator (which, based on the algorithms
you name, is what you're after), either buy an existing one or build it around
something like the Bluesteel or Hifn chips. For DSP-based crypto the best
bang per buck currently seems to be the 21065 SHARC, but this changes every
few months (the 21160 and TI exquivalents are still too expensive, and the
AT&T/Motorola collaboration hasn't produced much yet apart from press releases).
For IPSEC you really need to look at IPSEC-targeted ASIC's, not DSP's.
>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).
I have a paper which examines this in the pipeline, it may be available in
a few months.
Peter.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: EOF in cipher???
Date: 22 Feb 2000 16:42:52 GMT
"Douglas A. Gwyn" [EMAIL PROTECTED] writes:
>Runu Knips wrote:
>> I do not think that many of the people which argued here aren't
>> experienced in programming. Too, as long as you just write (for
>> text files):
>> _____________________________________
>> int ch;
>> FILE *f;
>>
>> f = fopen (name, "r");
>> while ((ch = getc (f)) != EOF) {
>> ...
>> }
>> _____________________________________
>> you're safe according to (AFAIK) ANYONE which posted here.
>
>No! In fact, you have duplicated the error that started this
>thread.
Runu's code looks correct for text opening and reading text files.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: How Useful is Encryption as Long as NSA Exists?
Date: Tue, 22 Feb 2000 15:42:49 GMT
[EMAIL PROTECTED] wrote:
> As you all know there are rumors that Microsoft Windows products
> have an NSA backdoor.
As you all *should* know, since that was already discussed here,
this concerns the second module authentication key, which has
its own problems but is clearly not an NSA backdoor.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: UK publishes 'impossible' decryption law
Date: Tue, 22 Feb 2000 16:49:41 GMT
In article <[EMAIL PROTECTED]>,
Eric Smith <[EMAIL PROTECTED]> wrote:
> I wrote:
> > The DDoS attack will probably *always* be possible.
> > Encrypting TCP connections (or IP) will not prevent it.
>
> Jerry Coffin <[EMAIL PROTECTED]> writes:
> > You're right -- in fact, I doubt any but the most ignorant
politicos
> > and such who've looked at it think anything being contemplated will
> > really stop DoS attacks. There's still some hope and help
available
> > from cryptography in general though: if every packet is signed,
> > tracking down the originator of a packet becomes a lot easier...
>
> That only will help if the compromised systems keep logs of the
originators
> of packets that they receive. And of course, the first thing the
people
> that compromise those systems will do (if they are smart, or if the
person
> who wrote the tools they use is smart) will be to delete such logs.
>
> Given that we're talking about machines that aren't very well secured
today,
> it's unlikely that they will have fancy logging of all packet
originator
> signatures in the future.
>
> Besides, if a major site such as Yahoo started requiring the request
> originators to provide authenticated requests, don't you suppose that
a
> lot of people would switch to a competing site that didn't?
>
That's not the point. a DoS attach is always _possible
I could launch one right now by going out to
a paypohone and repeatedly dialing the operator.
But the idea is to *catch and *punish the originator
of the DoS (even if only by blacklisting him)
and thus to reduce the number of DoS attachs that
can be expected.
As for people abandoning a site that required too
much security, some would and some wouldn't.
So what? Those that want security get it, and
those that dont, dont. As with everything.
Perhaps Yahoo could offer two different flavors.
The thing that annoys me is that now, those that
want security can't get it due to underuse of
cryptography.
--
Do as thou thinkest best.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
