Cryptography-Digest Digest #929, Volume #8 Tue, 19 Jan 99 05:13:03 EST
Contents:
Re: Why does the GOP hate encryption? [no PGP content] ("Rats")
Re: An idea for an Encryption Algorithm ... thoughts please. ("John Enright")
Re: SSL - How can it be safe? ([EMAIL PROTECTED])
Re: interview (JPeschel)
Re: Java speed vs 'C' (was Re: New Twofish Source Code Available)
([EMAIL PROTECTED])
Re: An idea for an Encryption Algorithm ... thoughts please. (Terry Ritter)
Re: interview (Terry Ritter)
Site Changes and Another Contest (JPeschel)
Re: Export laws ("Trevor Jackson, III")
Re: New Twofish Source Code Available ("John Enright")
Re: Trusts (Anonymous)
Re: sci.crypt intelligence test. (Paul Rubin)
Re: Java speed vs 'C' (was Re: New Twofish Source Code Available) (Ian Miller)
Re: interview ("Mr. Brisket")
Re: Dumb Question: Relationship between RSA and Factoring (Gurripato (x=nospam))
Re: sci.crypt intelligence test. (Terje Mathisen)
Re: An idea for an Encryption Algorithm ... thoughts please. (wtshaw)
Re: SSL - How can it be safe? (Soeren Mors)
----------------------------------------------------------------------------
From: "Rats" <[EMAIL PROTECTED]>
Subject: Re: Why does the GOP hate encryption? [no PGP content]
Date: Tue, 19 Jan 1999 14:05:46 +1300
Quite simple ... he who controls information ... controls the world.
Rats
------------------------------
From: "John Enright" <[EMAIL PROTECTED]>
Subject: Re: An idea for an Encryption Algorithm ... thoughts please.
Date: Mon, 18 Jan 1999 19:28:37 -0700
Well, a very obvious flaw here is simply encrypting a single byte at a time.
If an adversary knows (or can guess) some portions of the message or data
structure, he can probably piece it together with a quick brute force
attack. The reason being that none of the bytes are dependent on each other
for their security, thereby giving you only 256 possibilities for each byte
(which, by the way is nicely laid out in the correct order in a 1 to 1 size
corrolation). You really need much larger numbers to avoid efficient brute
force attacks in a scheme like this. ...right? I'm only just slightly past
the newbie stage myself. It's also probably not all that difficult to find
the orignal random number seeds of the variety you're suggesting.
Sounds like a slightly more elaborate Caeser Cipher to me.
Rats wrote in message <780b4a$kk8$[EMAIL PROTECTED]>...
>There are 256 chars in the ASCII set. 256 -> 8 bits (a byte).
>
>Use a Seed to scramble the 256 chars and get an initial condition for a
code
>wheel.
>
>Extract a byte of data from a stream and encrypt it using the code wheel.
>
>Create another code wheel using the first code wheel and encrypt the next
>byte extracted from the stream.
>
>Repeat until data is encrypted.
>
>
>I guess depending on how the intitial conditions are being setup and how
the
>code wheel is created from the previous code wheel would decide how secure
>the method is.
>
>Any thoughts and comments.
>
>Thanks in advance.
>
>Rats
>
>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: SSL - How can it be safe?
Date: Tue, 19 Jan 1999 01:30:10 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Doug Stell) wrote:
First off, thanks for the reply. It cleared a lot of things up. I have few
follow-up questions though:
> Correct. The public key is contained in a certificate and the CA's
> key, used to verify the certificate, is known to the browser a priori.
So any site that has SSL has to have the CA send out their public key? It
sounds like the browser has the CA's public key embedded in it's binary at
compile time also?
> No, it is the data encryption key that is 40/128 bits. The public key
> used for master key transport or agreement is much longer, 512/1024
> bits. The international version is limited to a 512-bit key by the
> U.S. export regulations.
Ok, I think I need to do some reading on PKI then. If the first packet is
encrypted with 512bit, how does that make it "easier" for the govt to break
it? I always assumed that the 40bit (international) version was 40bit because
it was easy for the feds to break, but if they have to get through a 512bit
layer first, that seems to be sufficient enough security.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: interview
Date: 19 Jan 1999 02:58:23 GMT
Phred Dobbs <[EMAIL PROTECTED]>, after coming back with bags of gold dust,
writes:
9) Do you require any licensing for your job?
Licensing? We dont need no stinkin' licensing!
Joe
(a Bogart fan, whose impulse got the better of him).
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Java speed vs 'C' (was Re: New Twofish Source Code Available)
Date: Tue, 19 Jan 1999 01:46:08 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Some trials I carried out some time ago (between Microsoft's Visual J++
> V1.0 and Visual C++ (I think V4.2)) suggested that C++ could be
> expected to be around five times faster than Java (maybe that wasn't
> JIT compiled, though??).
Pick up the high performance java compiler from alphaworks at IBM.
It compiles Java to native x86.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: An idea for an Encryption Algorithm ... thoughts please.
Date: Tue, 19 Jan 1999 03:48:24 GMT
On Tue, 19 Jan 1999 11:04:53 +1300, in
<780b4a$kk8$[EMAIL PROTECTED]>, in sci.crypt "Rats"
<[EMAIL PROTECTED]> wrote:
>There are 256 chars in the ASCII set. 256 -> 8 bits (a byte).
>
>Use a Seed to scramble the 256 chars and get an initial condition for a code
>wheel.
>
>Extract a byte of data from a stream and encrypt it using the code wheel.
>
>Create another code wheel using the first code wheel and encrypt the next
>byte extracted from the stream.
>
>Repeat until data is encrypted.
>
>
>I guess depending on how the intitial conditions are being setup and how the
>code wheel is created from the previous code wheel would decide how secure
>the method is.
>
>Any thoughts and comments.
With a handwave example like this, it's hard to know just what the
scheme really is. But it might be just about a step away from Dynamic
Substitution, which I own. See:
http://www.io.com/~ritter/#DynSubTech
http://www.io.com/~ritter/GLOSSARY.HTM#DynamicSubstitutionCombiner
http://www.io.com/~ritter/CLO2DESN.HTM
The goal of Dynamic Substitution is to strengthen a stream cipher by
using something other than exclusive-OR (or addition) to combine a
pseudorandom confusion stream with data. We want this because an
additive combiner has absolutely no strength against a known-plaintext
attack.
The idea of Dynamic Substitution is to encipher data by using a
different Simple Substitution for every byte ciphered. We could do
this by re-shuffling the table after every byte. But that would be
wasteful, because only one byte of the table is been exposed when a
single byte is enciphered. So we instead exchange the used byte with
any byte in the table (selected by the continuing pseudorandom
sequence), thus making the whole table again completely unknown. This
gives us an efficient, nonlinear, but also reversible mechanism for
combining data and confusion.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: interview
Date: Tue, 19 Jan 1999 03:48:38 GMT
On 19 Jan 1999 02:58:23 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (JPeschel) wrote:
>Phred Dobbs <[EMAIL PROTECTED]>, after coming back with bags of gold dust,
>writes:
>
>9) Do you require any licensing for your job?
>
>Licensing? We dont need no stinkin' licensing!
That's true.
Unless, of course, we offer ourselves for hire to the public as an
"Engineer," in which case a license is required.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Site Changes and Another Contest
Date: 19 Jan 1999 04:17:36 GMT
I have made some changes to my site.
First, I've eliminated the frames for those who dislike them.
I'll soon be adding a page on algorithms -- their descriptions,
implementations,
and attacks. Some of those algorithms will include the AES candidates,
but also such stuff as FEAL, Akelarre, and Skipjack. Maybe the latter
will be a useful supplement to Schneier's cryptanalysis course. Maybe it
won't -- c'est la guerre...
Also added a scott19u contest to, ahem, the contest section. No money
involved this time, but as Mr. Scott says, "The first person to solve it
Gets to gloat that he was the first to solve it."
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
Date: Mon, 18 Jan 1999 23:28:11 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Export laws
Bill Unruh wrote:
> In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (wtshaw)
>writes:
> >national who perhaps never set foot in the US might be difficult. To put
> >the burden on the ISP to verify residency and citizenship would require
> >some legislation.
>
> The legislation is already there, under the export regulations. It is
> illegal to export certain things without a license. It is also by
> defintionin the regulations that placing something on the internet unrestricted is by
> itself export-- no need for anyone else to actually get it. Thus if the
> ISp knows about the article, or should know about it, then his allowing
> it to be downloaded in an unrestricted manner is already export and
> against the law.
>
> >The only practical thing to do under those circumstances would be for the
> >government to keep an eye out for abuses, and order ISP's to do something
> >about such files when discovered by them or the government.
>
> That order is already there. It is called a regulation. The govenment
> does not have to point out to people to comply withthe law, except by
> publishing the reglations, which it has done.
Regulations are not laws. Until they have been tested in court, they are not even
reliable
guides to behavior. Statutory law is much more reliable than regulatory "law".
------------------------------
From: "John Enright" <[EMAIL PROTECTED]>
Subject: Re: New Twofish Source Code Available
Date: Mon, 18 Jan 1999 20:04:39 -0700
fungus wrote in message <[EMAIL PROTECTED]>...
>Bruce Schneier wrote:
>> No. It makes no sense to. These are all performance improvements,
>> and there's really no such thing as good performance in Java (for
>> pretty much of anything).
>
>That's strange...my matrix munching programs run faster in Java
>than in C++.
Then it's either making use of a native code library or your C++ program is
VERY inefficient.
------------------------------
From: Anonymous <[EMAIL PROTECTED]>
Subject: Re: Trusts
Date: 19 Jan 1999 07:26:07 +0100
=====BEGIN PGP SIGNED MESSAGE=====
Dale R Worley wrote ...
>In article <[EMAIL PROTECTED]> Anonymous <[EMAIL PROTECTED]>
writes:
> They claim that this is secure because it's
> infeasible to spoof a TCP/IP session, ie mount a
> man-in-the-middle attack by replacing the exchanged
> DH-keys on-the fly.
>
>Well, surely it's *possible* to do a man-in-the-middle attack, since
>(obviously) if you've been watching all the packets flying back and
>forth since the beginning of the TCP/IP session, you know the state at
>both ends of the connection. But it's a lot *harder* to do that than
>it is to eavesdrop on the packets as they go by -- not only do you
>have to have the power to substitute your packets for the real ones,
>but the tap has to actively interpret the packets and generate the
>spoof packets (compute-intensive, for DH and for de- and re-encrypting
>packets), rather than just recording them. My guess is it's a useful
>increment of security given the application, but not to be fully
>trusted. But since the system (obviously) has no way to truly
>authenticate the people on each end, it's no weaker than it appears to
>be.
Which would be more feasible, mounting a man-in-the-middle
attack or mounting a Tempest attack? Let's assume that
the attacker has access to the ISP of the target.
- --EO
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.0.2
iQEVAwUBNqQEM3lLzQ4ghnFxAQG/QQf9FXRE63RIXfMKbPMdHj/rBVpj1+ZoDnJ6
BSjtnFPJQ24dMyAMtPX2yiWlhKmyhEP5iT8l/hnW1pb+zCAjMf+kSm6qEQ2mF9Pa
yEX1elePgKvOaMDhVcbPuV7GRFRXOIBuieMBAtgff+V6iiaWSqkW7ikmT5mOkOZq
ZzaV6IJbzwFFEAkVVFVQRZYK89ZDam+hbHinEvzpC4EYtZaE4qkQnkiMFgCVkOC/
ZT0PGtCqwrC0yf3LsyysXGAyR//bHUwrponpFpnEiwWvmGYRHyIxGID6GOCcj0QN
N5X5WCzb5lFOYanqqO4C6H2GWn/wWhnyvEK/HRkfV+RYp1PCJ7JXXA==
=ocnv
=====END PGP SIGNATURE=====
------------------------------
Crossposted-To: talk.politics.crypto
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: sci.crypt intelligence test.
Date: Tue, 19 Jan 1999 08:23:45 GMT
In article <[EMAIL PROTECTED]>,
Terje Mathisen <[EMAIL PROTECTED]> wrote:
>This is (AFAIK) more or less the approach used by the Norwegian
>military, i.e. XOR-ing the data stream with the output of a fairly long
>LFSR, with the initial state of the shift register (possibly including
>the tap points) being the session key.
Um, I hope the Norwegian military doesn't really use plain LFSR's for
cryptography. Methods of reconstructing the LFSR state have been
known for decades...
------------------------------
From: [EMAIL PROTECTED] (Ian Miller)
Subject: Re: Java speed vs 'C' (was Re: New Twofish Source Code Available)
Date: Tue, 19 Jan 1999 07:36:05 +0000
In article <[EMAIL PROTECTED]>,
Daniel James <[EMAIL PROTECTED]> wrote:
>
>Interesting - I'd have expected Java to fare much worse against
>optimized code like this.
I am not surprised. In the long term, i.e. once compiler/processor
technology has moved on a little, the quality of the programming is far
more important than the language it was written in. The most extreme
example of this is assembler code, which is fastest in the short term but
freezes the code in the technology of the time. _Any_ high-level language
on next generation of hardware with a decent compiler will out-perform it.
e.g. The IDEA implementation used in the Mac version of PGP2.3 used 68020
assembler. However on a 68030 (only a slightly more advanced processor),
the pure C version ran 25% faster.
>Some trials I carried out some time ago (between Microsoft's Visual J++
>V1.0 and Visual C++ (I think V4.2)) suggested that C++ could be
>expected to be around five times faster than Java (maybe that wasn't
>JIT compiled, though??).
Microsoft has put a vast amount of effort into its C++ optimiser as this is
used to build most of the software it sells. Their commitment to Java is
much more recent and much more equivocal. I don't think MSVJ++ v. MSVC++
is the best comparison of the languages.
Ian
---
The above e-mail is temporary and will be discontinued presently. For a
currently valid address see http://www.bifroest.demon.co.uk/address.html
------------------------------
From: "Mr. Brisket" <[EMAIL PROTECTED]>
Subject: Re: interview
Date: Mon, 18 Jan 1999 22:57:37 -1000
Phred Dobbs (take out the q to email me) wrote:
>
> I am a senior in High School and I am taking an independent study
> mentorship
> class in Cryptography. I am looking for people in the cryptography field to
> interview. I just need someone who uses cryptography at all on the job,
> and I just need to ask 10 questions. I would greatly appreciate it.
> You can email me at [EMAIL PROTECTED] or just reply here, although
> emails
> will catch my attention.
>
> The questions are as follows if anyone wants to just answer them:
>
> 1) How did you get into cryptography?
After designing chips at Intel for 3 years, I was assigned a project
designing a crypto-chip.
> 2) Do you feel that your work is demanding compared to other jobs?
No, it is easy and fun.
> 3) What kinds of people do you work with?
Electrical engineers, computer scientists, programmers, marketing,
lawyers, Vice Presidents of major corporations, Indians, Chinese, French,
Vensuelan.
> 4) Do you enjoy what you do?
Yes, it is fun. My boss does not understand what I do, so I do whatever I
want.
> 5) Where did you get your training?
The University of Connecticut School of Engineering. Also Dr. Martin
Hellman trained me near Stanford University. (Of Diffie-Hellman fame).
> 6) Have you ever worked in military or defense cryptography?
No, and I never will. I have ethics.
> 7) Do you intend to utilize your knowledge in some way other than how you
> use it now, if so then how?
Yes. For free people. Later.
> 8) What kind of education did you need?
Master of Science in Electrical Engineering. Lots of math studies
independently, number theory.
> 9) Do you require any licensing for your job?
No, but the CIA and NSA check my work out and tell me their results.
> 10) What are your responsibilties on the job?
That information is available on a need to know basis (and you don't need
to know).
> 11) How difficult was it to find employment?
Easy.
> 12) What is your yearly salary/hourly pay?
$85,000 per year salary.
> All of them are of course optional, but answer if you can.
>
> Much thanks,
>
> Phredrick Dobbs ([EMAIL PROTECTED])
You're welcome (false name used)
------------------------------
From: [EMAIL PROTECTED] (Gurripato (x=nospam))
Subject: Re: Dumb Question: Relationship between RSA and Factoring
Date: Tue, 19 Jan 1999 08:10:00 GMT
On 18 Jan 1999 00:52:50 GMT, [EMAIL PROTECTED] (Dean Povey) wrote:
>Okay, call this a dumb question but...
>
>That the security of RSA is equivalent to factoring is only a conjecture, but
>would it be fair to say that any method of recovering the private key is
>equivalent to factoring (as p and q can be efficiently computed from
>e, d and n).
>
The problems is, factoring seems to be the only workable
strategy, but it is NOT proved that RSA security is defined by the
factoring problem. That is, there might be some other strategy that
works better than factoring (one that the NSA would certainly love to
know, if they don�t already).
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: sci.crypt intelligence test.
Date: Tue, 19 Jan 1999 08:53:12 +0100
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > sci.crypt intelligence test.
> >
> > #1)
> >
> > 10110001 (XOR) 01111101 = 11001100. Is this a legal operation? Is it
> > against the law to perform this operation using a general purpose
> > computer in most countries? Know of any exceptions?
> >
> Not personally, but I *sincerely* suggest that you don't take my word for it!
>
> > #2)
> >
> > Is there any law restricting the creation and use of any random number
> > generator? These come in many different forms and are included in every
> > computer operating system / compiler in the world.
> > I emailed the Commerce Dept. and the BXA and they said that there are
> > restrictions on encryption software. (Like: dah.) But they never did
> > reply when I asked them if there were any import / export restrictions
> > on random number generation software. Very interesting.
This is (AFAIK) more or less the approach used by the Norwegian
military, i.e. XOR-ing the data stream with the output of a fairly long
LFSR, with the initial state of the shift register (possibly including
the tap points) being the session key.
> Pin 'em down, then go for it! Just don't hang around waiting for someone to
> draft you up a personally hand-engr
This is beyond silly.
The only thing the US have achieved with the export restrictions on
"strong crypto", is to make a large protected market for non-US vendors.
(I guess they have also delayed wide deployment by a few years.)
I.e. when we need to implement a secure VPN connection over the
Internet, or just within the company Intranet, we simply install a
package written in Germany or Israel.
Public keys used for session key negotiation, IDEA or triple DES to
encode the data stream, automatic renegotiation of the session key after
a configurable number of KB's have been transferred.
American vendors are simply not in the running.
"We can sell you a 40-bit system, and since Norway is a Nato country you
might be approved for 56 bits if you'll just apply to the US State
Department."
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: An idea for an Encryption Algorithm ... thoughts please.
Date: Tue, 19 Jan 1999 01:08:01 -0600
In article <780b4a$kk8$[EMAIL PROTECTED]>, "Rats"
<[EMAIL PROTECTED]> wrote:
> There are 256 chars in the ASCII set. 256 -> 8 bits (a byte).
It is hardly a standard set above 127.
>
> Use a Seed to scramble the 256 chars and get an initial condition for a code
> wheel.
Single seed security, 15 or 16 bits probably
>
> Extract a byte of data from a stream and encrypt it using the code wheel.
>
> Create another code wheel using the first code wheel and encrypt the next
> byte extracted from the stream.
An extension of the single seed
>
> Repeat until data is encrypted.
>
>
> I guess depending on how the intitial conditions are being setup and how the
> code wheel is created from the previous code wheel would decide how secure
> the method is.
You are well into cyclic alphabetic systems, good luck.
Encryption based on graduating ciphertext from one wheel to another is
something I exploit quite successfully.
--
Clinton should have been a Tobacco Company President, one of
thoses that got a pass for purjury. Who knows the millions of people who will die
because they were part of a conspiracy to hide the truth. They benefit from the
protection they paid, the bribes
commonly called political contributions. Put current events in
prospective, and consider the hypocracy of Congress in all this.
------------------------------
From: Soeren Mors <[EMAIL PROTECTED]>
Subject: Re: SSL - How can it be safe?
Date: 19 Jan 1999 10:01:41 +0100
[EMAIL PROTECTED] writes:
> Ok, I think I need to do some reading on PKI then. If the first packet is
> encrypted with 512bit, how does that make it "easier" for the govt to break
> it? I always assumed that the 40bit (international) version was 40bit because
> it was easy for the feds to break, but if they have to get through a 512bit
> layer first, that seems to be sufficient enough security.
You can't compare keylengths in that way. You are correct that the
limitations are there to ensure that the "feds" can indeed break the
crypto. But the 512 bit key is the key to a asymetric or Public-key
system which is used to encrypt a key for a symmetric or traditional
cryptosystem. Symmetric cryptosystems can get a lot more "security
pr. bit" that the assymetric ones, they are also a *lot* faster.
--
Soeren Mors
Student of Computer Science at DAIMI [EMAIL PROTECTED]
Student programmer at Cryptomathic A/S [EMAIL PROTECTED]
------------------------------
** 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
******************************
