Cryptography-Digest Digest #345, Volume #11 Thu, 16 Mar 00 08:13:01 EST
Contents:
Re: how to introduce hs students to cryptography ("Douglas A. Gwyn")
Re: Really Interested, Where do I look for ... ("Douglas A. Gwyn")
Re: Novice questions ("Douglas A. Gwyn")
SALT with RC4, where do I store the SALT? (Impervious)
Re: [Tabloid Humor] Greatest threat ever to computer security ("Steven Alexander")
Re: US export status of RC4? (Bill Unruh)
java code for ellipse curve cryptography and ripme-160 (kingtim)
Re: new Echelon article (Eliot Walsh)
Re: new Echelon article ([EMAIL PROTECTED])
OAP-L3 encryptionn software download files (Anthony Stephen Szopa)
Re: Looking for a special one way function ("Joseph Ashwood")
Re: NIST, AES at RSA conference ("Joseph Ashwood")
Re: SALT with RC4, where do I store the SALT? ("Joseph Ashwood")
Re: SALT with RC4, where do I store the SALT? (Impervious)
Re: Q: Voice encryption (Mark Currie)
A weird DES crypt() question (Michel Dalle)
Re: On jamming interception networks (jungle)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: how to introduce hs students to cryptography
Date: Thu, 16 Mar 2000 02:12:52 GMT
Andru Luvisi wrote:
> That all depends on the "youngster". Although this is fine for most
> students, *requiring* that all students follow your
> works-for-most-people speed and level will still frustrate the slow
> ones and frequently bore the bright kid in the front row and turn him
> into an underachiever.
That's a standard educational issue, to be addressed by educators in
ways they already understand. Certainly, presenting too-advanced
material to a general-level class will guarantee general disaster.
The "bright kid" can explore further and deeper on his own (with
teacher support).
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Really Interested, Where do I look for ...
Date: Thu, 16 Mar 2000 02:18:50 GMT
jack wrote:
> 1.) Where can i find on the web the higher
> math info i need to know on the web? Most
> of the info i found is not a teaching aid
> or tutorial. I looked but most of the
> stuff i found didn't "teach". I don't want
> to wait till i learn it all in college.
The WWW is not designed to be an instructional agent.
Your best bet would be to learn from *textbooks*,
preferably ones with plenty of well-designed exercises.
You can browse at a university bookstore,
or ask for textbook recommendations in specific areas.
(Try searching Amazon.com and read the book reviews.)
For number theory, Ore's book (paperback) is a good place
to start.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Novice questions
Date: Thu, 16 Mar 2000 02:21:09 GMT
[EMAIL PROTECTED] wrote:
> I have created a simple encryption program and would like to know if
> its "allowable" to post the source for people to review and comment.
In general, not in sci.crypt. (Read the sci.crypt FAQ.)
What you *can* do is ask anyone who is interested to contact
you to get a copy, or you can put it in some publicly accessible
place and post the URL here.
------------------------------
From: [EMAIL PROTECTED] (Impervious)
Subject: SALT with RC4, where do I store the SALT?
Date: Thu, 16 Mar 2000 03:16:52 GMT
Hi All,
I have mentioned previously about having written an encryption program
which is based on the RC4 algorithm. I am using SHA for hashing, but I
also wanted to incorporate salt into my program. Joe A. graciously
answered my salt questions and I now understand how to implement it,
but I forgot one issue - How do I store the salt in my encrypted file?
Obviously it would be the easiest to just append it to the end of the
encrypted file, but wouldn't doing something so obvious defeat its
purpose?
Most of the write-ups on salt talk about storing it in a separate file
(like for user/password verification), but I need to have the salt IN
my encrypted files.
Any input greatly appreciated!
Thanks,
Manuel
------------------------------
From: "Steven Alexander" <[EMAIL PROTECTED]>
Crossposted-To: alt.computer.security
Subject: Re: [Tabloid Humor] Greatest threat ever to computer security
Date: Thu, 16 Mar 2000 03:41:01 GMT
I had, put the 1745.html in there already...It gives me a 404 not found.
It's been moved...does anyone still have it sitting in their tempfiles, I'd
still like to read it. thanks.
-steven
Jeffrey Williams wrote in message <[EMAIL PROTECTED]>...
>Actually, it is working. It's just slightly incorrect. The "1745.html"
>is part of the link.
>
>Jeff
>
>Steven Alexander wrote:
>
>> Does anyone have a copy of this. The link is no longer working.
>>
>> -steven
>>
>> [EMAIL PROTECTED] wrote in message <8akf58$kt$[EMAIL PROTECTED]>...
>> >
>> >
>> >http://www.weeklyworldnews.com/stories/
>> >1745.html
>> >
>> >
>> >
>> >I'm going down, all the way down
>> >on the highway to Hell -AC/DC
>> >
>> >
>> >
>> >Sent via Deja.com http://www.deja.com/
>> >Before you buy.
>
>--
>Jeff Williams
>Software Design Engineer
>DNA Enterprise, Inc
>1240 E Campbell Rd, Richardson, TX, 75081
>972 671 1972 x265
>[EMAIL PROTECTED]
>
>Did you know that there is enough sand in
>north Africa to cover the entire Sahara?
>
>
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: US export status of RC4?
Date: 16 Mar 2000 04:16:45 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Impervious) writes:
>As far as the exporting regs... It looks like I won't be able to
>export the program without crippling it, so either I have to do all
>the extra work to be sure it stays in the US or I just won't release
>it to the public. I'm still glad I had the experience however. I think
>I now have the cipher bug! :)
Tell us more. As I saw the regs, if you publish the source and make it
freely available ( eg GPL) then you can export almost anything.
------------------------------
From: kingtim <[EMAIL PROTECTED]>
Subject: java code for ellipse curve cryptography and ripme-160
Date: Thu, 16 Mar 2000 12:28:02 -0800
please tell me where i can get java code for ellipse curve cryptography
thanks
------------------------------
From: Eliot Walsh <[EMAIL PROTECTED]>
Crossposted-To:
alt.politics.org.cia,alt.politics.org.nsa,alt.journalism.print,alt.journalism.newspapers
Subject: Re: new Echelon article
Date: Thu, 16 Mar 2000 05:46:05 GMT
Does Echelon filter out the term "hum-job"?
[EMAIL PROTECTED] wrote:
> On Wed, 15 Mar 2000 10:41:11 +0100, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
>
> >If there were a robot that is programmed to ferret out 'bribery'
> >informations out of the whole stuffs collected and destroy all the
> >rest, the scene would indeed have a different flavour. But there
> >are humans and these at different levels of payroles. Even if
> >the top-level ones were really all gentlemen, strictly performing
> >according to laws and instructions, how is one going to control
> >the conduct of a large number of the not-so-well-paid employees who
> >have materials constantly and secretly passing through their hands
> >that are worthy of hundreds of thousands of dollars?
>
> The spooks would might try to use "the conduct of a handful of
> uncontrollable low paid employees" as an excuse, but they would be
> stupid to do so because even _I_ could shoot that one down. To wit,
>
> 1. The CIA/NSA are directly involved in this, and from the top
> (Commander in Chief) down. To wit, this contact (aka "Bob Beamer") who
> was feeding intelligence info to Dept of Commerce. Those packets of
> info Huang was allegedly feeding to Lippo certainly weren't concerned
> strictly with bribery.
>
> 2. If the spooks can't control the "low paid and uncontrollable with a
> profit motive," the agencies must be riddled with a zillion Aldrich
> Ames ready to give away the family jewels to the highest bidder. It's
> American, heroic and patriotic to supply information to a friend of
> Slick Willie's for a campaign contribution???? Perhaps at the expense
> of the corporate lives of other American businesses???? Did they sign
> on willingly to become the unsung heroes and honored financially
> dead???? No star on the wall at McClean for them.
>
> 3. It's not uncontrollable; it's coordinated. The CIA in their
> recruitment advertising indicate that a cover might be that of an
> American businessman working abroad. Shell corporations like Air
> America can be ferretted out. If you're going to have a cover of, say,
> an employee of Microsoft, you have to have Microsoft credentials, work
> in a Microsoft office and have the total appearance of being a
> Microsoft employee.
>
> So don't believe this crap about "we can't control it" or "it's good
> for the American way of life." Those scumbags are cashing in and the
> only American way of life their interested in is their own: "Red neck,
> white socks and blue chip stocks."
>
> Follow the money.
>
> Best, Mac
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.politics.org.cia,alt.politics.org.nsa,alt.journalism.print,alt.journalism.newspapers
Subject: Re: new Echelon article
Reply-To: [EMAIL PROTECTED]
Date: Thu, 16 Mar 2000 06:24:08 GMT
On Wed, 15 Mar 2000 00:19:02 GMT, [EMAIL PROTECTED] wrote:
>
>
>http://www.wired.com/news/politics/
>0,1283,34932,00.html
It's a rewrite. The original article, penned by Duncan Campbell, the
author of the report to the European Parliament on Echelon, is at
http://www.heise.de/tp/deutsch/special/ech/6662/1.html
Some reader comments at the article's end are kind of interesting. One
fellow is tying it to the destruction of "INSLAW" and Busy Bee
Equipment, a maker of wafer steppers.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: OAP-L3 encryptionn software download files
Date: Wed, 15 Mar 2000 22:26:03 -0800
OAP-L3 encryption software download files at http://www.ciphile.com
There was a problem with the example data self extracting .ZIP files.
These have been changed to plain old .ZIP files (NOT self extracting)
They download properly now.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Looking for a special one way function
Date: Wed, 15 Mar 2000 13:36:34 -0000
Actually you have made an error in your O() statement. Your
time taken is actually O(n(O(f())). Dropping it down to O(1)
would be rare, but it is possible to (under some
circumstances) get O(f()).
If you can solve for f^n() generically, and place it in the
form g(X,n) = f^n(X), then your speed will be O(g()), which
you should be able to do optimally. There are not many
useful functions in this category barring ones where the
optimal expression of g is the f(f(......)) function you had
already.
If you cannot solve for a generic f^n(), but can solve for
some subsets, it is possible to build f^n() out of K g()
computations, each with their own timings. This may or may
not be optimal, but there is a great wealth of functions in
this category.
If you cannot solve for any f^n() except 1. I'm sorry,
you're out of luck. There are excessicely few, if any
functions in this category.
Good luck, hope you remember your algebra.
<[EMAIL PROTECTED]> wrote in message
news:8aocs6$ql1$[EMAIL PROTECTED]...
> I am looking for a special one way function that has the
following
> properties:
> Assume f is the one way function, the computation cost of
f is C.
> Xi+1 = f(Xi)
> Generally, compute Xn from X1 needs computation cost
(n-1)C, which is in
> the order of O(n). Here is my question: Is there any one
way function
> that can computer Xn from X1 at a cost of O(1) or O(lgn)?
> Thanks,
> Shine
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Wed, 15 Mar 2000 13:49:21 -0000
Actually my problem was WITH the authentication mechanism,
if and only if the authentication method authenticates the
ciphertext. If the authentication method authenticates the
plaintext my argument is null and void, as it should be.
This flaw was demonstrated through an attack on an
RSA-encrypted document, which was subsequently signed.
Joe
> I think "imply" already contains the "necessarily".
> Clearly the solution to the problem Joseph Ashwood
> observed is the authentication mechanism.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: SALT with RC4, where do I store the SALT?
Date: Wed, 15 Mar 2000 22:59:56 -0000
Your salt can be freely known, as you noted it can be
appended to the end of the file, it can be placed at the
beginning, if your salt is small enough you can search for
it, it can be the time of encoding, pretty much any way that
you can get it from point a to point b is sufficient. Any
known location will work.
Joe
"Impervious" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi All,
>
> I have mentioned previously about having written an
encryption program
> which is based on the RC4 algorithm. I am using SHA for
hashing, but I
> also wanted to incorporate salt into my program. Joe A.
graciously
> answered my salt questions and I now understand how to
implement it,
> but I forgot one issue - How do I store the salt in my
encrypted file?
> Obviously it would be the easiest to just append it to the
end of the
> encrypted file, but wouldn't doing something so obvious
defeat its
> purpose?
>
> Most of the write-ups on salt talk about storing it in a
separate file
> (like for user/password verification), but I need to have
the salt IN
> my encrypted files.
>
> Any input greatly appreciated!
>
> Thanks,
> Manuel
------------------------------
From: [EMAIL PROTECTED] (Impervious)
Subject: Re: SALT with RC4, where do I store the SALT?
Date: Thu, 16 Mar 2000 09:03:16 GMT
On Wed, 15 Mar 2000 22:59:56 -0000, "Joseph Ashwood"
<[EMAIL PROTECTED]> wrote:
>Your salt can be freely known, as you noted it can be
>appended to the end of the file, it can be placed at the
>beginning, if your salt is small enough you can search for
>it, it can be the time of encoding, pretty much any way that
>you can get it from point a to point b is sufficient. Any
>known location will work.
> Joe
Thanks again Joe. Could I bug you for one more thing? Below is part of
the simple salt code (visual basic) I thought about implementing. It's
a 10 character salt which uses only the A-Z characters. I didn't write
it, I got it from a website:
randomize
Salt = ""
For I = 1 to 10
Salt = Salt & chr(int(rnd*26)+65)
Next
My questions are:
1) Is there an advantage to having more characters in the salt? Can I
have a 40 character salt for example?
2) Is there a reason the person who wrote the code above limited it to
A-Z characters only? I see no reason to limit the salt this way...
Can't I just use all available ASCII characters? Perhaps there is no
real advantage to doing that, and that is why it was written that way?
Thanks again Joe... I wish I had more of a talent for math (it was
always my worst subject)
Manuel Alvarez
------------------------------
Subject: Re: Q: Voice encryption
From: [EMAIL PROTECTED] (Mark Currie)
Date: 16 Mar 2000 11:08:21 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>>Mark Currie wrote:
>>
>> One reason for using stream ciphers is that they can be made into
>> self-syncronising ciphers that automatically correct themselves when errors
>> occur on the line. Unlike data, voice has to be real-time, i.e. you can't waste
>> time re-transmitting voice packets that have failed due to errors. On the
>> question of which algorithm to use - most block ciphers can be turned into
>> self-synchronising stream ciphers.
>
>Actually you can do a surprising amount of traffic management with voice. There's a
>company with so
>me fundamental patents in this area -- type-based encoding and compression -- named
>I-Link. The pat
>ents are fundamental to good voice-over-IP. The type-based encoding lets you mix
>voice, fax, modem,
> etc. streams on the same wire (fiber). It is about two orders of magnitude more
>effective (in engi
>neering units) than point-to-point telephony connections.
>
>In business terms, $, the comparison with existing infrastructure is interesting. It
>costs about 2.
>8 cents per minute for a long distance provider to support a pure voice telephone
>call. That cost p
>rovides something of a floor to long distance rates. Those rates will decline with
>technological ad
>vances but the fundamental technology is over 100 years old, so we don't expect
>sudden decreases. W
>ith effective coding and compression it costs only 0.02 cents per minute to support a
>voice call. M
>ostly this is due to the fact that while voice is real-time at 1 sec resolution, it
>is no where near
> real time at 1 ms resolution. So there's a lot of room for managing voice traffic,
>and the opportu
>nity to mix many voice streams over a single channel.
>
Have you tried any of these systems between countries where at least one of the
countries does not have a lot of spare bandwidth on their
internet feed ? There are still many cases where telecomms can be more reliable for
encrypted speech.
>Given a packetized data stream, mixed or not, adding error and cipher protection
>costs only a little
> processing power. There's no fundamental restriction that says voice requires a
>self-synchronizing
> stream cipher.
I agree, but that's not what I said. I only said "One reason for using...".
Self-synchronising ciphers can be useful in telecomms since turn-around times for
re-transmissions can be slow, especially if you go via
satellite. There are other techniques that can be used but each have their own set of
problems.
I am not sure what you mean by "voice is real-time at 1 second". Regular 1 second
delays in the middle of a spoken word can be quite nasty.
However, I in now way want to punt old technology and infrustructure as being the way
to go for the future. I merely wanted to point out that
at this point in time, it still has a place.
Mark
------------------------------
From: [EMAIL PROTECTED] (Michel Dalle)
Subject: A weird DES crypt() question
Date: Thu, 16 Mar 2000 11:43:30 GMT
With the traditional Unix password encryption scheme,
is it theoretically possible to find a set of characters for
the input, so that the output will always have certain
characters at certain places (for a fixed salt) ?
For example, suppose I have a couple of encrypted
passwords with the following pattern : .abcd...
Can anything be said about the different passwords
that would generate this, for a given salt ? Or is this
truly a one-way operation ?
And if we assume that passwords always use a
certain character set (e.g. lower-case alphabet), could
the number of passwords that would match this pattern
after encryption be determined ?
Thanks for any pointers,
Michel.
------------------------------
From: jungle <[EMAIL PROTECTED]>
Subject: Re: On jamming interception networks
Date: Thu, 16 Mar 2000 12:18:36 GMT
how to get grip of this speech ? on internet, please ...
"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:
> > Now, how do I know whether I am or I am not on their watch list?
>
> That is irrelevant; hopefully you don't have access to that
> information. My point is that the vast majority of people are
> *not* targets of surveillance, and in particular communication
> strictly between US citizens is not targeted by US intelligence
> agencies except under certain limited, controlled conditions
> (such as when there is probable cause that the persons are
> involved in espionage or terrorism).
>
> > What are the precise criteria for a person to have the honour
> > of being on that list?
>
> There are precise criteria, but for security reasons nobody
> is going to tell you what they are. You can get a feel for
> them from Hayden's speech to the Kennedy Political Union.
how to get grip of this speech ? on internet, please ...
------------------------------
** 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
******************************
