Cryptography-Digest Digest #124, Volume #9 Tue, 23 Feb 99 07:13:03 EST
Contents:
Re: Snake Oil (from the Feb 99 Crypto-Gram) (Terry Ritter)
Re: Anyone know of any good stream chipers? ("Bruce Christensen")
Re: Anyone know of any good stream chipers? ("Bruce Christensen")
Re: Randomness based consciousness?. (Was: Re: *** Where Does The Randomness Come
From ?!? *** ) (tiger9)
Re: Crypt for FTP Protocol (Bryan Olson)
Re: Testing Algorithms (Somny)
Re: Testing Algorithms (Safuat Hamdy)
Re: Anyone know of any good stream chipers? (Safuat Hamdy)
Re: Scramdisk File ("Sam Simpson")
Re: Crypt for FTP Protocol (Thomas Wu)
Interesting DES results (bill johnson)
Re: IDEA test vectors? ("Sam Simpson")
Re: 128 bit encryption (Jerry Park)
Re: Another extension to CipherSaber ("Jay")
Re: Crypt for FTP Protocol ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Snake Oil (from the Feb 99 Crypto-Gram)
Date: Tue, 23 Feb 1999 04:22:22 GMT
On Sun, 21 Feb 1999 16:08:03 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] (Bruce Schneier) wrote:
>On Sat, 20 Feb 1999 23:24:01 -0600, Mark Andreas <[EMAIL PROTECTED]>
>wrote:
>
>>Bruce Schneier wrote:
>>
>>> Some companies claim "military-grade" security. This is a meaningless
>>> term. There's no such standard. And at least in the U.S., military
>>> cryptography is not available for non-government purposes (although
>>> government contractors can get it for classified contracts).
>>
>>The first time I remember seeing this phrase was when using the
>>command-line version of PGP 2.6 using the -kg switch to generate a key.
>>Choice #3 was:
>>
>>3) 1024 bits- "Military" grade, slow, highest security
>
>Slooppy terminology. Good idea, but sloppy terminology.
I have just been looking at a web-ad from VeriSign:
"Secure Server ID. Military-grade solutions for any size business.
FREE 14 day trial. CLICK HERE. VeriSign."
(http://www.verisign.com/cgi-bin/go.cgi?a=b001100430100100)
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Bruce Christensen" <[EMAIL PROTECTED]>
Subject: Re: Anyone know of any good stream chipers?
Date: Tue, 23 Feb 1999 04:36:53 GMT
Swapping two letters is a common mistake with typing on a keyboard, not need
for the nasty reply to a honest question.
>>A chiper that would require at least a $10,000 investment to crack
>Please learn how to spell in English. The word is "cipher", not
>"chiper".
------------------------------
From: "Bruce Christensen" <[EMAIL PROTECTED]>
Subject: Re: Anyone know of any good stream chipers?
Date: Tue, 23 Feb 1999 04:39:11 GMT
Should have been "no need" rather than "not need". Everyone makes
mistakes, but this stuff is off-topic, and should not have been posted by
me. Apologies to the group;
Bruce
------------------------------
From: [EMAIL PROTECTED] (tiger9)
Crossposted-To:
sci.skeptic,sci.philosophy.meta,sci.psychology.theory,alt.hypnosis,sci.logic
Subject: Re: Randomness based consciousness?. (Was: Re: *** Where Does The Randomness
Come From ?!? *** )
Date: Mon, 22 Feb 1999 15:17:29 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I can agree with that, except that I as far I know
> there is no real known reason for anything to exist.
Nor does anyone else know the "reason" no matter how hard they try
with the most eloquent words!
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Crypt for FTP Protocol
Date: Mon, 22 Feb 1999 21:55:35 -0800
[EMAIL PROTECTED] wrote:
>
> My users have repeatedly asked if I could add crypt/cipher to my FTPD [...]
> I've looked at "ssh" ofcourse, and if you wanted to just crypt the
> control-session it would be fairly straight-forward to tunnel it, but since
> it is required to crypt the data-sessions as well it makes it more
> complicated. (Far beyond your average user I suspect?) Although ssh2 comes
> with what looks like a library of sorts, ssh2's licence makes it pretty much
> useless in that sense. The "sftp" that comes with it breaks FTP-Protocols
> too much to be really used (still basic ssh challange before it drops down
> into FTP-style protocols).
To some extent you're going to have to break the protocol. Obviously
the client and server are both going to have to deal with the encryption,
and then there's the FTP firewall problem. As I'm sure you know, FTP
won't work if a firewall only allows outbound connections, since to
transfer files from the server to the client, the server initiates the
connection. Modern fireballs use application level proxies which
understand the control channel and therefore know that the incoming
connection is a response to a client request.
If the channel is end-to-end encrypted, then an application level proxy
won't work since it can't read the data. A transport level SSL proxy
can't tell that an incoming connection request is legitimate.
Life would be much easier with a file transfer protocol in which all
connections were initiated from the same side. This is a well known
problem, and there may be updates to protocols that I haven't followed.
[...]
> The idea is to add something "not too complex" - to make merging with existing
> FTPD and FTP client code fairly straight forward.
Just about anything off the shelf is going to be easier than rolling
your own. Check out SSL, which provides a secure transport.
--Bryan
------------------------------
From: Somny <[EMAIL PROTECTED]>
Subject: Re: Testing Algorithms
Date: Mon, 22 Feb 1999 22:40:01 -1000
Trevor Jackson, III wrote:
>
> Coen Visser wrote:
>
> > [EMAIL PROTECTED] writes:
> > > [EMAIL PROTECTED] (Coen Visser) wrote:
> > >> fungus <[EMAIL PROTECTED]> writes:
> > I suggest you look at what was stated: "So you think a 256 bit key will
> > eventually be brute forced?"
> > ^^^^^^^^^^
> > How can you claim that your (engineering) knowledge is still valid 50
> > or 500 years from now? I think eventually is a pretty long time.
> >
> > >What is it that drives people to make these wild claims and speculations
> > >without doing the arithmetic? Computers can not continue to get faster
> > >indefinitely.
> >
> > Agreed, but the limits are not known.
>
> Actually some of the limits are known. The size of the observable universe puts
> an upper limit on the size of a useful computing device. The plank scale puts a
> lower limit on the size of a useful computer component. Ignoring energy usage and
> the speed of light, there are still definite limits which we cannot expect to
> pass.
>
> Yes, this is limited by our understanding of the universe, and thus subject to
> change. But if our concept of the universe does not change, then neither do the
> limits to computing. As far as I can tell there is no conceivable computing
> device that can enumerate the intergers up to 2^1000.
It is easier to count to 2^256 than it is to try 2^256 keys.
If you can count every photon emitted by every star in the
known universe, how long would it take to count 2^256 photons?
Here is the calculation:
There are 10^11 stars in our galaxy and 10^11 galaxies known.
The sun emits photons with power of 1 kilowatt per square meter on Earth.
A sphere around the sun 93 million miles in radius has this many
square meters:
4*pi*R^2 = 4*3.14*(1.5*10^9 meters)^2 = 2.8*10^19 sq m
So the power is 2.8*10^22 watt
The photon energy from a star is E=2.8*10^22 joules per second.
One photon has energy e=hc/wavelength h=6.6*10^-34js
e=(6.6*10^-34js)(3*10^8m/s)/(4000^10^-10m)= 5*10-19j
To get the total number of photons from a star per second find E/e
E/e = 5*10^42 photons per second per star
For all 10^22 stars in the known universe, the number of photons
per second is 5*10^64 or about 2^213 photons per second.
To find how long it would take to get 2^256 photons, divide by that
answer above. (2^256)/(2^213) = 2^43 seconds or 250 thousand years.
It takes all of the stars in the known universe 250,000 years to
emit about 2^256 photons.
So what?
There are 2^128 atoms in Mount Everest.
There are 2^64 atoms in a coin.
There are 2^292 particles in the known universe.
There are 2^908723489071389071348907 keys I can choose from easily.
So what? Moore's law is not a Law, it is a trend. Ask him if
he calls it a Law, or if some layman coined that phrase.
------------------------------
From: Safuat Hamdy <[EMAIL PROTECTED]>
Subject: Re: Testing Algorithms
Date: 23 Feb 1999 09:56:33 +0100
[EMAIL PROTECTED] (Patrick Juola) writes:
> In article <7arsl1$51j$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> >What is it that drives people to make these wild claims and speculations
> >without doing the arithmetic? Computers can not continue to get faster
> >indefinitely.
>
> The fact that doomsayers have been predicting physical limits to the
> maximum speed of computers for 20 years now, and the successive violation
> of these physical "limits" has become routine.
Bruce Schneier made some interesting estimates in AC about this. Don't have
the exact numbers in mind, but essentially the message was:
if one bit operation would require one elementary energy unit (this is a
hard, insurmountable limit) and the estimates about the complete available
energy in the whole universe were about correct (this might be wrong, but
even if it were, it wouldn't enhance the situation from a practical point of
view), then you even wouldn't be able to run through all values of a single
256-Bit counter. You'll admit that there's nothing simpler than
incrementing a counter.
i think scientists have learned the lesson and will make their estimates
much more carefully than 30 years ago.
--
S. Hamdy | All primes are odd except 2,
[EMAIL PROTECTED] | which is the oddest of all.
|
unsolicited commercial e-mail | D.E. Knuth
is strictly not welcome |
------------------------------
From: Safuat Hamdy <[EMAIL PROTECTED]>
Subject: Re: Anyone know of any good stream chipers?
Date: 23 Feb 1999 10:11:59 +0100
[EMAIL PROTECTED] (R. Knauer) writes:
> On Tue, 23 Feb 1999 13:26:27 +1300, "Rats" <[EMAIL PROTECTED]>
> wrote:
>
> >Definition of a "good" stream chiper according to me:
>
> >Now can you recommend one? As I mentioned before the algorithm is what I am
> >interested in not source code or exes.
>
> Please learn how to spell in English. The word is "cipher", not
> "chiper".
>
> You have to give more details, like how many messages of what length
> you plan to encrypt. The more you encrypt, the stronger the system you
> need.
Here we have an example of a really helpful hint ...
Anyway, I suggest anyone interested in stream ciphers to read
Cusick, T.W. and Ding, C.: Stream ciphers and number theory,
1998. 446 pp., North-Holland, ISBN: 0444828737
--
S. Hamdy | All primes are odd except 2,
[EMAIL PROTECTED] | which is the oddest of all.
|
unsolicited commercial e-mail | D.E. Knuth
is strictly not welcome |
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Scramdisk File
Date: Tue, 23 Feb 1999 09:19:23 -0000
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Jim Dunnett wrote in message <[EMAIL PROTECTED]>...
>On Sun, 21 Feb 1999 16:49:51 -0800, Gregg Berkholtz
<[EMAIL PROTECTED]>
>wrote:
>
<SNIP>
>>Now, what did you mean by giving the scramdisk more breathing room --
I don't
>>believe that scramdisk creates a swap file or any other file outside
of what I
>>intended it to create (the .SVL file).
>
>Don't know. Just an idea. Perhaps the author of the program can
>answer that.
No, it doesn't use any temporary space at all.
- --
Sam Simpson
Comms Analyst
http://www.hertreg.ac.uk/ss/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
If you're wondering why I don't reply to Sternlight, it's because he's
kill filed. See http://www.openpgp.net/FUD for why!
=====BEGIN PGP SIGNATURE=====
Version: PGP 6.0.2
iQA/AwUBNtJymu0ty8FDP9tPEQKIPgCfajZTqNDM2XFPSsHURJYbPSW0R5wAoKz2
cokY+bI9ZQkTrauYAGlxj61+
=x0Xb
=====END PGP SIGNATURE=====
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: Crypt for FTP Protocol
Date: 23 Feb 1999 01:25:50 -0800
Bryan Olson <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
> >
> > complicated. (Far beyond your average user I suspect?) Although ssh2 comes
> > with what looks like a library of sorts, ssh2's licence makes it pretty much
> > useless in that sense. The "sftp" that comes with it breaks FTP-Protocols
> > too much to be really used (still basic ssh challange before it drops down
> > into FTP-style protocols).
>
> To some extent you're going to have to break the protocol. Obviously
> the client and server are both going to have to deal with the encryption,
> and then there's the FTP firewall problem. As I'm sure you know, FTP
> won't work if a firewall only allows outbound connections, since to
> transfer files from the server to the client, the server initiates the
We've had success using SRP FTP in passive mode through firewalls.
The client initiates data connections, and since the protocol is an
FTP extension, the secure FTP daemon also handles standard FTP requests
without requiring an extra port or inetd.conf entry.
> connection. Modern fireballs use application level proxies which
^^^^^^^^^
Ouch!
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "The pen may be mightier than the sword, but my
Phone: (650) 723-1565 mouse can crash Windows with one click."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
Date: Mon, 22 Feb 1999 21:26:53 -0800
From: bill johnson <[EMAIL PROTECTED]>
Reply-To: same
Subject: Interesting DES results
Hello,
I'm new to this news group but I found something interesting. I was
interested in random numbers so I tried encrypting a file to produce
another file of random numbers. The encryption was done with a standard
DES engine with a single key, encrypting 8 bytes in sucession and
writing the values to a data file.
I then ran two tests on the data file (about 1.5MB). The first was to
count the number of different byte values (0 through 255) and as I
expected the results were very uniform with little deviation.
The second test was to measure the + or - difference from one byte to
the next. This was an eye opener. The plot looks like a nearly perfect
inverted 'V'. In fact amazingly so.
I've tried this on two different sources and I get the same result.
Any comments from the grouop? I have the data and source files if
anyone is interested.
Bill Johnson
remove 'nospam' to reply
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: IDEA test vectors?
Date: Tue, 23 Feb 1999 09:12:54 -0000
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
- From cryptlib:
Key: 00010002 00030004 00050006 00070008
Plaintext: 00000001 00020003
Ciphertext: 11FBED2B 01986DE5
- --
Sam Simpson
Comms Analyst
http://www.hertreg.ac.uk/ss/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
If you're wondering why I don't reply to Sternlight, it's because he's
kill filed. See http://www.openpgp.net/FUD for why!
Dominik Werder wrote in message <[EMAIL PROTECTED]>...
>HI!
>
>Where can I find test vectors for my IDEA implementation?
=====BEGIN PGP SIGNATURE=====
Version: PGP 6.0.2
iQA/AwUBNtJxE+0ty8FDP9tPEQLorgCgr/46uVt6evXvFwvSlUam/FHdaMUAoKAp
6mw3BsfihfFNjYXp5Rl5mbI9
=/N6d
=====END PGP SIGNATURE=====
------------------------------
From: Jerry Park <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: 128 bit encryption
Date: Tue, 23 Feb 1999 10:29:31 GMT
tomjudy wrote:
> I am a new user, a Canadian citizen presently living in Jamaica. I want
> to download 128bit encryption to do online banking but keep getting all
> kinds of nasty messages saying "no". Please help!!!
> --
> Posted via Talkway - http://www.talkway.com
> Surf Usenet at home, on the road, and by email -- always at Talkway.
You don't say what browser you are using (assume you want 128 bit
encryption in your browser). If using Netscape, go to
http://www.fortify.net/ for a patch to convert the browser to 128 bit
encryption.
--
Jerry Park
Affordable Production Tools
web site: http://www.apt.simplenet.com/
javascript utilities: http://www.apt.simplenet.com/javascript/
* Easiest email encryption system
------------------------------
From: "Jay" <[EMAIL PROTECTED]>
Subject: Re: Another extension to CipherSaber
Date: Tue, 23 Feb 1999 06:19:25 -0500
Bauerda wrote in message <[EMAIL PROTECTED]>...
> Actually, it would increase the key space by much more than that because
of
>the slowdown of discarding millions of bytes before getting to check and
see if
>the key is correct. It would, however, be decected by a timing attack:
>differences of a few seconds is easy to notice.
I don't think this will help. To be useful, the discard count must be in a
format that others can use, i.e. its location in the stream and function
must be known, or it must be a shared secret. If it is part of the encrypted
stream, the attacker can read it unambiguously for each possible key
transaction so its primary benefit will be some slowdown in setup. If it is
a shared secret, it is simply another form of key extension. A few bytes
longer key will have more effect on security. It's true that the pass phrase
has an eventual practical limit in Ciphersaber, but this is at a key length
that is reasonably secure for the forseable future.
Also, regarding the earlier suggestion of ASCII armoring, we already have
universal standards (like binhex or UUEncode) which accomplish this.
Ciphersaber is primarily meant to be easily implemented, and interoperable,
adding another level of complexity works against this critical function.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Crypt for FTP Protocol
Date: Tue, 23 Feb 1999 10:33:00 GMT
In article <[EMAIL PROTECTED]>,
Thomas Wu <[EMAIL PROTECTED]> wrote:
> It's been done. Take a look at SRP ftp/ftpd (http://srp.stanford.edu/srp/),
> which addresses most, if not all of your issues. It encrypts both data
> and control connections, supports strong 128-bit ciphers, retains the
Sweet! The perfect answer to my question! :)
> It's slightly more complicated than that - just remember that the best
> solutions perform some form of secure authenticated key exchange and use
> the exchanged key to encrypt the session. Also keep in mind that SRP is
> supported in third-party clients and servers, so that should help with
> compatibility issues.
This is what I was afraid of, that it would be way above my knowledge and I'd
end up doing something about as secure as XOR'ing everything.
Cheers,
Lund
> --
> Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
> E-mail: [EMAIL PROTECTED] "The pen may be mightier than the sword, but my
> Phone: (650) 723-1565 mouse can crash Windows with one click."
> http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
>
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
** 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
******************************
