Cryptography-Digest Digest #736, Volume #11 Tue, 9 May 00 00:13:01 EDT
Contents:
Encryption code or addons for VB? (Test51)
Encryption code or addons for VB? (Test51)
Re: Q: Searching for authentication protocols (Thomas Wu)
Re: Hardware RNG ("Joseph Ashwood")
Re: Why no civilian GPS anti-spoofing? / proposal (zapzing)
Re: Why no civilian GPS anti-spoofing? / proposal (zapzing)
Re: Why no civilian GPS anti-spoofing? / proposal (Dave Ashley)
Re: Any good attorneys? (Joaquim Southby)
Re: Why no civilian GPS anti-spoofing? / proposal ([EMAIL PROTECTED])
Re: Why no civilian GPS anti-spoofing? / proposal ([EMAIL PROTECTED])
Scary Possibility: Ticklish Chips (zapzing)
Another related key attack on GOST ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Test51 <[EMAIL PROTECTED]>
Crossposted-To: comp.programming
Subject: Encryption code or addons for VB?
Date: Tue, 09 May 2000 01:14:06 GMT
Hi,
I searched through recent posts of this group but couldn't find an
answer.
Does anyone know of any site out there that contain code or other addons
(DLL, ActiveX) to provide encryption in Visual Basic?
Thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Test51 <[EMAIL PROTECTED]>
Subject: Encryption code or addons for VB?
Date: Tue, 09 May 2000 01:14:34 GMT
Hi,
I searched through recent posts of this group but couldn't find an
answer.
Does anyone know of any site out there that contain code or other addons
(DLL, ActiveX) to provide encryption in Visual Basic?
Thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Q: Searching for authentication protocols
Date: 08 May 2000 18:41:52 -0700
Tomīs Perlines Hormann <[EMAIL PROTECTED]> writes:
> Hi there!
>
> I am searching for papers concerning authentication and key exchange
> protocols as Kerberos or others may be.
>
> First of all there is the need for authenticating several clients
> (students in remote lecture rooms) to a server (teacher) and exchanging
> their session key for allowing a secure communication (symmetric
> encryption).
>
> Further more, I want to focus on client-to-client authentication as it
> can happen in collaborative service models with several clients
> (students) working on a seminar sharing a secured channel. The issue is
> about authenticating each other and exchanging the session key.
>
> Where can I find more info about DH-based key exchange protocols and the
> Kerberos model? I am sure there must be lots of evaluations made
> depending on the particular needs.
>
> Thanks in advance.
If you're doing password-based authentication, the current state-of-the-art
consists of protocols like SRP and SPEKE. See:
http://srp.stanford.edu/srp/
http://www.integritysciences.com/
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Hardware RNG
Date: Mon, 8 May 2000 18:43:29 -0700
Thank you so much, that's exactly the kind of thing I was
looking for (anyone have any more?). I am basically looking
for a large number of random sources. I am then going to mix
this using something very similar to Yarrow. I am attempting
to build a RNG that should provide enough randomness that I
can feel confident calling it "secure". Of course you know I
have higher standards than almost anyone else, and for the
specific purpose I have in mind, I need to get as close to
true randomness as possible. BTW can someone give me details
on ANSI's Secure Random Number Generator standard? I know
it's just a test, but from what I've found they started with
DIEHARD and built from there.
Joe
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Crossposted-To: sci.geo.satellite-nav
Subject: Re: Why no civilian GPS anti-spoofing? / proposal
Date: Tue, 09 May 2000 02:36:43 GMT
In article <M2aR4.59506$[EMAIL PROTECTED]>,
"Mxsmanic" <[EMAIL PROTECTED]> wrote:
> "Paul Rubin" <[EMAIL PROTECTED]> wrote in message
> news:8f35o6$o7i$[EMAIL PROTECTED]...
>
> > I'd like to propose that civilian signals on
> > the new carriers have public-key digital signatures,
> > signed by the satellites.
>
> Just what part would you sign, exactly? Public-key encryption is not
> appropriate for every application.
>
> Since mission-critical navigation applications would supplement the
> satellite signals with a ground-based signal, spoofing of both would
be
> no more likely than spoofing of VOR or ILS signals today, even without
> encryption. In fact, I don't remember terrorists ever spoofing any
kind
> of navigation signal at all--have I missed something?
Maybe they hadn't thought of it yet. Oops.
But seriously, the idea is to try to
prevent problems before they occur, if
it is feasible to do so, and a public
key system seems like it would work very
well here and be reasonably low cost.
--
Do as thou thinkest best.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Why no civilian GPS anti-spoofing? / proposal
Date: Tue, 09 May 2000 02:46:09 GMT
In article <lOsR4.7372$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> > Nobody said that. A few state-backed terrorists steering a
> > few jumbo commercial airliners way off course would certainly
> > be sufficient to terrorize the public.
>
> I think my problem with the whole scenario is two-fold. First, I'm
> basically as anti-gps as you can get. Having firsthand experience
> using it, I find it of very limited use as an _aid to
> navigation_. That's not to say it's a bad idea, or a waste of money,
> just that it's primarily useful for doublechecking your current
> location.
But it could be better.
>
> Second, it just seems obvious to me that a state sponsored terrorist
> would have many cheaper/easier ways to terrorise air traffic than
> this.
>
Easier, perhaps, but cheaper? all they would need is
a transmitter.
> When you talk about sending planes off course though, the thought
> occours to me that while causing planes to collide is farfetched, it
> may be somewhat easier to keep one lost over the ocean long enough to
> run out of fuel, or some other navigational shenanegin.
Such as causing a plane to fly into a mountainside.
Yikes. We certainly don't want that to happen.
Why won't the fedgov let us have the anti-spoofing
signals to prevent such a catastrophie?
I think they *like* it when catastrophies happen,
so they can blame it on terrorists and then grab more
power from a terrified public.
>
> > The fact is, our technological infrastructure is exceedingly
> > fragile, a fact that has many people concerned (and occasionally
> > somebody actually working on the problem). The more one puts
> > his eggs all in one basket, especially a fragile one, the more
> > likely a catastrophe will occur.
>
> Well, as I said above, you should _not_ be putting your eggs all in
> the gps basket. Given that the navigator should still be navigating by
> hand, large deviations from the GPS fix will be obvious. The challenge
> then is to figure out which location is correct. Anywhere inside most
> nations air space this should be trivial, over blue water it's
> probably slightly more problematical.
>
> > The sad thing is that GPS is a nearly ideal application for
> > public-key cryptography (everybody could decode, but only the
> > system itself could encode), which would have solved the
> > spoofing problem.
>
> I don't know, my experience with gps is limited to little black boxes
> that I plugged into other little boxes. ;) I would think though, that
> there would always be at least an impractical spoofing
> attack. Assuming somehow the system sent a signal that everyone could
> decode, which only it could generate. Then, if I wanted you to think
> you were at point B rather than point A, why couldn't I go to B and
> transmit the signal to you? Assuming the points were close enough that
> you didn't notice the time difference, your equipment would assume it
> was at B.
>
simply include the current time in the signature,
and put clocks in the little black boxes.
> --
> Matt Gauthier <[EMAIL PROTECTED]>
>
--
Do as thou thinkest best.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Dave Ashley <[EMAIL PROTECTED]>
Subject: Re: Why no civilian GPS anti-spoofing? / proposal
Date: Tue, 09 May 2000 03:13:29 GMT
You bums on this newsgroup are really beginning to worry me. One of
you is probably building a transmitter right now and waiting for a zero-
visibility day at the airport.
Sick puppies!
I'm worried.
Dave.
In article <8f7u5e$pdr$[EMAIL PROTECTED]>,
zapzing <[EMAIL PROTECTED]> wrote:
> In article <lOsR4.7372$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> > > Nobody said that. A few state-backed terrorists steering a
> > > few jumbo commercial airliners way off course would certainly
> > > be sufficient to terrorize the public.
> >
> > I think my problem with the whole scenario is two-fold. First, I'm
> > basically as anti-gps as you can get. Having firsthand experience
> > using it, I find it of very limited use as an _aid to
> > navigation_. That's not to say it's a bad idea, or a waste of money,
> > just that it's primarily useful for doublechecking your current
> > location.
>
> But it could be better.
>
> >
> > Second, it just seems obvious to me that a state sponsored terrorist
> > would have many cheaper/easier ways to terrorise air traffic than
> > this.
> >
>
> Easier, perhaps, but cheaper? all they would need is
> a transmitter.
>
> > When you talk about sending planes off course though, the thought
> > occours to me that while causing planes to collide is farfetched, it
> > may be somewhat easier to keep one lost over the ocean long enough
to
> > run out of fuel, or some other navigational shenanegin.
>
> Such as causing a plane to fly into a mountainside.
> Yikes. We certainly don't want that to happen.
> Why won't the fedgov let us have the anti-spoofing
> signals to prevent such a catastrophie?
> I think they *like* it when catastrophies happen,
> so they can blame it on terrorists and then grab more
> power from a terrified public.
> >
> > > The fact is, our technological infrastructure is exceedingly
> > > fragile, a fact that has many people concerned (and occasionally
> > > somebody actually working on the problem). The more one puts
> > > his eggs all in one basket, especially a fragile one, the more
> > > likely a catastrophe will occur.
> >
> > Well, as I said above, you should _not_ be putting your eggs all in
> > the gps basket. Given that the navigator should still be navigating
by
> > hand, large deviations from the GPS fix will be obvious. The
challenge
> > then is to figure out which location is correct. Anywhere inside
most
> > nations air space this should be trivial, over blue water it's
> > probably slightly more problematical.
> >
> > > The sad thing is that GPS is a nearly ideal application for
> > > public-key cryptography (everybody could decode, but only the
> > > system itself could encode), which would have solved the
> > > spoofing problem.
> >
> > I don't know, my experience with gps is limited to little black
boxes
> > that I plugged into other little boxes. ;) I would think though,
that
> > there would always be at least an impractical spoofing
> > attack. Assuming somehow the system sent a signal that everyone
could
> > decode, which only it could generate. Then, if I wanted you to think
> > you were at point B rather than point A, why couldn't I go to B and
> > transmit the signal to you? Assuming the points were close enough
that
> > you didn't notice the time difference, your equipment would assume
it
> > was at B.
> >
>
> simply include the current time in the signature,
> and put clocks in the little black boxes.
>
> > --
> > Matt Gauthier <[EMAIL PROTECTED]>
> >
>
> --
> Do as thou thinkest best.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
--
=================================================
Dave Ashley, [EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Joaquim Southby <[EMAIL PROTECTED]>
Subject: Re: Any good attorneys?
Date: 9 May 2000 03:24:08 GMT
In article <[EMAIL PROTECTED]> Trevor L. Jackson,
[EMAIL PROTECTED] writes:
>It depends on the jurisdictional boundaries that are crossed. If A manufactures a
>device in a jurisdiction (J1) where it is legal to do so and sells the device
>(distributes it) to B, and B imports it into a jurisdiction (J2) where it infringes
>upon a patent and uses it, then A has not infringed the patent, but B has. If the
>sale from A->B happens within the J2, then AFAIK, A has infringed the patent. Note
>that even though A was the original infringer in the second example, B's use of the
>patented device within J2 is also an infringement that the patent holder can enjoin.
>
I think we're in agreement on both these scenarios. I'm a little taken
aback at the user's liability since he may not know what's in the package
he's using, but then ignorance of the law yadda yadda.
<PGP stuff snipped>
>> >Thus I believe your conclusion is flawed by the application of copyright
>> >principles to the domain of patents. You may want to reread the portion of my
>> >post that you snipped.
>> >
>> You are right. I shouldn't have used illegal downloads of copyrighted
>> software as an example. The portion of your post you refer to is not
>> relevant to my argument since I don't believe the end user is liable or
>> responsible for a patent violation in a product they received from
>> someone else. I'll have to run that one by the patent lawyers at my
>> company next week for their opinion.
>
>I'll be interested in the opinion. In the past users have been enjoined from using
>patented technology even though they were not the "manufacturer" or "distributor".
>In the absence of this consideration, would-be violators could set up dummy
>companies, manufacture the rip-off products for themselves, and be immune to the
>consequences of enforcement of the patent upon the dummy. Consider, for example,
>patents that are never licensed, but used to distinguish a company from its
>competitors.
>
I talked to a friend of mine who is an ex-programmer/present patent
attorney. She told me that she doesn't know a thing about the subject
since their job is to develop the patents, not defend them. She referred
me to the corporate attorneys and helped me don my armor.
The trip to corporate attorney land was an experience. They are only a
stone's throw from the executive offices and miles away from any open
door policy. I went in, gave my name, and asked our basic questions
about liability. They wanted to know why I was asking. I told them it
was to augment a discussion on Usenet. They wanted to know what Usenet
was. When I told them, they huddled together for some moments and then
began a strange dance. Almost too late, I realized it was a decoy to
draw my attention away from the two circling to cut me off from the door.
I bullrushed them, knocking one to the floor, and managed to escape with
only two Super StickOn Subpoenas (tm) plastered to my back. Fortunately,
I hadn't given my real name (sorry, Trevor, but you're being sued for
sexual harassment and charged with mopery).
Seriously, once I had asked the questions, the guy I talked to went into
another office, came back with his boss and they asked me about Usenet,
etc. They conferred for a while and then told me they could not comment.
Hmmm...sounds like there's a company that's working on a similar
problem, doesn't it? Sorry I couldn't get any valid opinions. I tried
some other lawyerly friends and even a judge, but none of them were any
help.
>> In any case, you seemed to be taking issue with my usage of the term
>> "distribution" even though I was trying to agree with you in the first
>> place that there could be dispute about that term.
>
>Mostly because it is hard to analyze products as slippery as freeware. Since there's
>no money involves the author has no knowledge of the users, and may not have any form
>of contact with the majority of the users because there can be an arbitrarily large
>number of intermediaries who copy the software (with the blanket permission of the
>author), and who might be better characterized as "the distributor".
>
In the case under discussion, though, wouldn't the originator of the
tainted software still be culpable, no matter what the chain of
distribution looked like?
>> I was trying to
>> illustrate that point with my reference to copyrighted software on a
>> Hotline server. Let's change that to "software containing patented
>> algorithms". Do you believe that anyone should be able to use a patented
>> algorithm in a piece of software and either sell it, give it away, or
>> make it available for download without compensating the holder of the
>> patent?
>
>AFAIK, compensation to the holder of the patent is not relevant. Permission is
>relevant. (Of course permission may require compensation ;-)
>
>Your question does not address the issue of multiple patent jurisdictions. Within a
>single jurisdiction, one cannot legally sell, give away, or make available for
>download any patented product/technology/algorithm. Nor can one use it without the
>patent holder's permission.
>
>Can anyone not in the jurisdiction of a patent sell a piece of software that would
>infringe if sold within the patent jurisdiction? Yes. Can one give it away? Yes.
>Can one make it available for the download? Yes. The third point is the only sticky
>one. I reached the affirmative conclusion by reasoning that forbidding the
>downloading of the software would prohibit legitimate activity, which rules out the
>blanket prohibition on downloading software. In support of this we can observe that
>the person who moves the software from outside the patent jurisdiction to within the
>patent jurisdiction is the one responsible for the infringement. That action,
>"infringing distribution" if you will, is the action that is prohibited by the
>existence of the patent.
>
>A logical extension of this line of reasoning leads to the conclusion that while one
>cannot sell or give away patented technology within the patent jurisdiction, one
>could make it available for download. If we presume that the software is offered
>with the proviso that users within the jurisdiction would have to seek the permission
>of the patent holder then in theory there is no infringement. I suspect this
>conclusion is far out on thin ice.
>
I'm not sure logic and the US Patent Office are in sync yet on Internet
technologies. Apparently RSA is taking the tack opposite to your
conclusion by saying that Tom is at fault for making the software
available within the patent jurisdiction. I think this is the same
problem that arises when taxing the Net -- where does the transaction
occur? The software physically resides on a server in Canada, yet it is
being advertised (via Web pages, in a loose sense of the word) to the US.
If someone in the US downloads the software, where does the transaction
take place? We agree that the downloader, being within the patent
jurisdiction, is liable for infringement no matter what, but is the
provider of the software acting within that jurisdiction also? I think a
case could be made for that.
Of course, this could all be mental masturbation our part if it turns out
that RSA holds patents in Canada, too.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why no civilian GPS anti-spoofing? / proposal
Date: Tue, 09 May 2000 03:26:30 GMT
zapzing <[EMAIL PROTECTED]> wrote:
> Such as causing a plane to fly into a mountainside.
> Yikes. We certainly don't want that to happen.
> Why won't the fedgov let us have the anti-spoofing
> signals to prevent such a catastrophie?
This is nonsensical. Except for _very_ limited corridors, commercial
airliners would be flying well above the highest elevation on the
map. Since the altimeter is a mechanical device, it wouldn't be
affected by gps problems.
> simply include the current time in the signature,
> and put clocks in the little black boxes.
Synchronising every reciever to the same clock without using the gps
signal would be a nightmare. And I'm still not sure it's possible to
timestamp an stream of data. Which brings us to the sci-crypt
relevance. Is it possible to authenticate the route broadcast data
traveled, rather than just the origin?
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why no civilian GPS anti-spoofing? / proposal
Date: Tue, 09 May 2000 03:27:57 GMT
Dave Ashley <[EMAIL PROTECTED]> wrote:
> You bums on this newsgroup are really beginning to worry me. One of
> you is probably building a transmitter right now and waiting for a zero-
> visibility day at the airport.
It won't work at the airport, because the planes are under ATC. ;)
Unless, of course, we go for an unlikely scenario like a certain
Die-Hard movie.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Scary Possibility: Ticklish Chips
Date: Tue, 09 May 2000 03:19:02 GMT
Here's something to keep you awake at night:
What if some of the chips for doing DES etc. have
been made "ticklish" , that is what if some
sort of irritant, such as a dose of radiation
or an electrical input that is out of band
would prompt the chip to divulge its key.
This could be bad if bad guys manage to
steal your (otherwise tamper proof) encryption
device. Any ideas on how to prevent this,
(other than by just trying to make your
packaging impervious to all possible tickles,
which seems to me to be pretty hopeless) ?
It seems like one thing you could do is
superencrypt using chips from several
different antagonistic countries. It
would be unlikely that the bad guys could
manage to get all their tickle signals.
Internal whitening might also work.
Don't bother to tell me I'm paranoid:
I already know that. But that doesn't mean
they arent out to get me :)
--
Do as thou thinkest best.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Another related key attack on GOST
Date: Tue, 09 May 2000 03:20:42 GMT
Hey sci.crypt,
I have come up with a modest attack on GOST. I believe it will break
GOST 2^32 times faster than exhaustive search. The attack is a related
key attack of the rotational sub-key variety. The attack assumes known
s-boxes in GOST, not an unreasonable assumption.
Several other people have helped me develop it so I cannot take all the
credit.
Suppose we have two 256-bit keys. Let the letters represent 32-bits
(1) ABAA AAAA
(2) AABA AAAA
These two keys only have 64-bits of secret info but a similar attack
applies for keys with more secret bits.
The full key schedule of GOST will yield.
ABAA AAAA ABAA AAAA ABAA AAAA AAAA AABA
AABA AAAA AABA AAAA AABA AAAA AAAA ABAA
Note but sliding one round, the keys agree up to the 28/29 round.
ABAAAAAAABAAAAAAABAAAAAAAAAA AABA
AABAAAAAAABAAAAAAABAAAAAAAAAA BAA
Now if we guess the 'A' key, can trim off the outside rounds
BAAAAAAABAAAAAAABAAAAAAAAAA AAB
BAAAAAAABAAAAAAABAAAAAAAAAA B
We can now produce equal input into the last three/one round because
the key schedule match exactly.
AAB
B
We can now break the last 32 bits of the key. Let the input be (L,R).
The F function is denoted by the key letter
L R L R
B A
R L' R L''
A
L'' R'
B
R' L'''
>From the left hand side we have the input 'R'. From the right hand
side,
R' ^ R = F(L''+A)
Since everything expect L'' is known, L'' can be calculated from the
sboxes.
Now we have
L'' ^ L''' = F(B+R')
Everything expect B is known so 'B' can be calculated.
By guessing 'A', 'B' can be found trivially thus the cipher is broken
about 2^32 faster than exhaustive search.
If a full key is used all but the last 32-bits must be guessed. I
suspect that a better cryptographer could extend the attack.
--Matthew
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
******************************
