Cryptography-Digest Digest #50, Volume #10 Sun, 15 Aug 99 10:13:03 EDT
Contents:
Re: Cracking the Scott cryptosystems? (JPeschel)
Re: NIST AES FInalists are.... (SCOTT19U.ZIP_GUY)
Re: Cracking the Scott cryptosystems? (SCOTT19U.ZIP_GUY)
Re: Clerification of Crypto Export Laws (JPeschel)
Re: Clerification of Crypto Export Laws (David A Molnar)
Re: With all the talk about random... (Herman Rubin)
Re: Triple DES (168bit) -- Triple DES (112bit)
Re: Positive News About JAWS Technologies (dave)
Re: Cracking the Scott cryptosystems? ([EMAIL PROTECTED])
Re: Compact Full-Keying Twofish Code? (Ruud de Rooij)
Re: NIST AES FInalists are....
Re: New encryption algorithm ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Cracking the Scott cryptosystems?
Date: 15 Aug 1999 05:13:34 GMT
>[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) quotes:
[EMAIL PROTECTED] who wrote:
>>If you want to
>>make money by cracking a grand-total of two 35K documents ... forget
>>it. Buy Red Hat instead.
>Actually you can get the Red Hat code for free. Or has something changed
>that you have to pay money to get it now.
I'd say he was talking about buying into the recent Red Hat IPO.
I'd wait to for the PPI numbers Tuesday, though, before I bought
anything. Is this answer sufficiently cryptic to be considered on topic?
:-)
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NIST AES FInalists are....
Date: Sun, 15 Aug 1999 06:01:36 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>> Well as for brute force if the keyspace is flat the fastest method is
>> parallel linear searches. No matter what algorithm you use it will not
>> be faster then testing all keys sequentially (unless the keyspace is
>> not flat).
>
>That is an incredible assertion. What is the mathematics behind it?
>It sounds like a very important theorem, if true. (As you might
>infer, I do not think it is true.)
I think Little Tommy boy must be on dope.
>
>> BTW I seriously doubt in the 70's they had the ability to search the
>> DES keyspace in less then a year.
>
>You would lose your bet.
Obvisously the kid can''t read. We had ECL stuff that was fast. It is a
hell of a lot easier to build specail hardware to crack quickly than
to program a machine. There where many critcics of DES in the open
publication at the time. But hell Tommy was only a gleem in his
fathers eye during that period of time.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Cracking the Scott cryptosystems?
Date: Sun, 15 Aug 1999 05:56:13 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>> Is there a reason why this form of cryptosystem isn't generally used?
>
>David seems to think it is an NSA-led conspiracy, but actually there
>are numerous more thoroughly understood systems that people think
>work well enough, so there is little motivation to work on a new one.
>The most serious problem, though, is the large key size, which makes
>key management a much bigger problem than usual.
Actually key management is no more a problem than it is for
PGP. What one would most likely have is a large keyenc.key
file. And then the use what you want as a pass word. You can
change the big keyenc.key only when you feel like it.
>
>> It appears, although I don't have enough background in information
>> theory to prove it, that there is not enough information provided in
>> this system, because stages (A) and (C), given the small file size
>> and different starting positions this seems effectively to be a one
>> time pad. Is this correct?
>
>If a different key file (S-box generator input) were used for each
>message, then it would have similar characteristics to a one-time
>pad. Note that one-time pads aren't often used in practice either.
It seems to me that all good crypto systems should act like
a OTP if a different key is used for "EACH MESSAGE" since
it is the only provable secure method. WAKE UP
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Clerification of Crypto Export Laws
Date: 15 Aug 1999 05:24:55 GMT
>[EMAIL PROTECTED] writes:
>2) If someone used a half baked encryption scheme (just something that
>they made up), does it still apply to the Laws? (Something like
>shifting, xoring, etc, nothing big)
Hardly seems worth the bother of getting a license. Many shareware
companies and re-distributors don't bother with getting a license
at all and haven't had any trouble.
I think the ACA still has come classical ciphers on its web page.
John Savard or Jim G. might know whether it needed a license
to make those available. I would guess not.
A while ago, I think Doug Gwyn posted some code that would XOR
to files with each other. He didn't seem terribly worried about it.
If it were me, I would post the code and not lose any sleep.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Clerification of Crypto Export Laws
Date: 15 Aug 1999 07:57:59 GMT
[EMAIL PROTECTED] wrote:
> I have a few questions, if anyone could shed some light I would be very
> thankful:
> 1) If you reduced the key down to 40 bits (or whatever the US government
> allows), do I still have to clear the program with the US government?
> 2) If someone used a half baked encryption scheme (just something that
> they made up), does it still apply to the Laws? (Something like
> shifting, xoring, etc, nothing big)
Technically you are supposed to obtain a license for all exports of
cryptography outside the U.S. It's just that the process is supposed to be
cursory in the case of 1), and is often overlooked in the case of 2).
By "cursory" I mean on the order of a week from application to license.
I've heard that it doesn't work this way in practice; in particular, I
remember hearing that Matt Blaze attempted to get a crypto export license
as an exercise and found himself running up against ye olde bureaucracy.
http://www.bxa.doc.gov/Encryption/elaguide.htm
contains some official-looking info, including a number to call for
"export counseling." Some months ago, I mistakely thought that an export
license would be required to give crypto software to foreign nationals
residing in the U.S. (it turns out crypto "export" means physically taking
out of a country, not "releasing to a foreign national" the way it used
to. Allah be praised.) SO I called the number over a weekend and
received no reply.
If you actually have a product, maybe they'll get back to you. :-\
-David
------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Subject: Re: With all the talk about random...
Date: 1 Aug 1999 13:53:36 -0500
In article <[EMAIL PROTECTED]>,
Robert C. Paulsen, Jr. <[EMAIL PROTECTED]> wrote:
>Herman Rubin wrote:
>> There are stochastic effects, due to imperfections and thermal
>> noise, which increase the lack of determinacy. If we roll the
>> die far enough, quantum indeterminacy in the actions of other
>> objects will introduce randomness.
>That seems like a natural explanation to me too, but when I made
>such a suggestion in another thread a few weeks back several people
>replied saying essentially that ...
>a) There was no quantum indeterminacy involved in dice rolling, and
>b) quantum indeterminacy was not required to get true randomness
>from rolling dice.
>As far as I know, the only behavior in the universe known to
>involve true randomness is is from quantum effects.
>Other stochastic effects, chaos, complexity, etc. are just ways of
>describing or dealing with situations where we lack enough
>information to make predictions based on the underlying determinacy,
>even though this information is obtainable in principle.
>It is not unheard of for quantum randomness to make itself known on
>a macroscopic scale -- a Geiger counter is the obvious example.
>Perhaps rolling dice is another example. I really don't know if the
>results of dice rolling actually is effected by quantum
>indeterminacy but it would be interesting to see a "proof" one
>way or the other.
I have no idea how complicated the quantum-mechanical interactions
of a die rolling would be, or even the classical situation going
down to the atomic level, but it would certainly require major
simplifications to get anything which could be analyzed.
I was once told by a physicist that if one dropped a perfectly
elastic steel ball on another identical one from its height, the
expected number of bounces before it fell off would be about 3.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
From: <[EMAIL PROTECTED]>
Subject: Re: Triple DES (168bit) -- Triple DES (112bit)
Date: Sun, 15 Aug 1999 10:14:38 +0200
On Sat, 14 Aug 1999, karl malbrain wrote:
>
> Frank Piepiorra <[EMAIL PROTECTED]> wrote in message
> news:7p1eib$p69$[EMAIL PROTECTED]...
> > Several publications refer to Triple DES with the key size 168 bit or 112
> > bit. Both seems to have Triple DES but what in detail, besides the key
> > length :-) is the difference and does it have an impact on security?
> > Frank
>
> The key size never materially exceeds 64 bits with a 64 bit block cipher.
> Triple DES materially extends the original 56 bit key size to 64 bits. Karl
> M
>
You are definitively wrong: There are (2^64)! possible permutations of 64
bit words. These are more than 2^(2^64) possible permutations and this way
as many possible keys for a cipher.
3DES with is's 2^168 possible keys produces only a small subset of these
keys.
Of course for a single block you can't get more output-blocks than the
2^64 OTPs of this size, but for longer messages the number of possible
sequences grows.
Andreas Enterrottacher
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: dave <[EMAIL PROTECTED]>
Subject: Re: Positive News About JAWS Technologies
Date: Sat, 14 Aug 1999 15:08:12 GMT
No bet, Tom....not even canadian $.
They do mention "cumulative XOR" too.
"Patent Pending" essentially means that the patent office has
acknowleged receipt of an application, and confers no protection other
than established priority. It may mean something more if a patent is
actually granted, but this is a classic shut the barn door after the
horse is out. The patent examiner is going to be looking for "new",
"novel", and "not obvious to one skilled in the field" in the
application before granting the patent.
It'll be a while yet before we see patent disclosure on JAWS
(I'm not a lawyer, but I've seen a few excited inventors go past my
door, and they all want patents. Problem is....if GM wants your super
carb, GM will have your super carb, and you cannot afford the litigation
to enforce your patent).
There was an article in one of the local business mags about JAWS, and
it was headed by a photo of these fellows and gals standing around in
suits with their arms folded and gazing sternly into the camera.
Looked like a poster for "Men In Black"
DaveM
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cracking the Scott cryptosystems?
Date: Sun, 15 Aug 1999 11:03:54 +0200
SCOTT19U.ZIP_GUY wrote:
>
> In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> >[EMAIL PROTECTED] wrote:
> > ...
> Is there a reason why this form of cryptosystem isn't generally used?
> >
> >David seems to think it is an NSA-led conspiracy, but actually there
> >are numerous more thoroughly understood systems that people think
> >work well enough, so there is little motivation to work on a new one.
> >The most serious problem, though, is the large key size, which makes
> >key management a much bigger problem than usual.
> Actually key management is no more a problem than it is for
> PGP. What one would most likely have is a large keyenc.key
> file. And then the use what you want as a pass word. You can
> change the big keyenc.key only when you feel like it.
>
So how do you exchange the key for a message without an public-key
method?
> >
> >> It appears, although I don't have enough background in information
> >> theory to prove it, that there is not enough information provided in
> >> this system, because stages (A) and (C), given the small file size
> >> and different starting positions this seems effectively to be a one
> >> time pad. Is this correct?
> >
> >If a different key file (S-box generator input) were used for each
> >message, then it would have similar characteristics to a one-time
> >pad. Note that one-time pads aren't often used in practice either.
> It seems to me that all good crypto systems should act like
> a OTP if a different key is used for "EACH MESSAGE" since
> it is the only provable secure method. WAKE UP
I don't think this behaviour tells anything about the strength of the
system:
1) A vernam cipher behaves like an OTP as long as the key is longer than
the message but it can simply be broken for longer messages.
2) DES doesn't show this behaviour even for a single block since it
generates only 2^56 of the possible 2^64 permutations, but for longer
messages it is much stronger than a vernam cipher.
If you want to use a OTP - why not?
But for a cipher that should be used daily I'd prefer one with the
properties of a modern blockcipher:
- The key should be just long enough to keep the attacker from trying
brute-force-attacks. If I'm using passwords it is already hard
enough to memorize a phrase that contains enough entropy and that
isn't
part of a book or a poem. An when using public-key-encryption long
keys are slowing down the whole system.
- The cipher should be small and fast. I don't want to store huge
lookup-tables on my computer without knowing whether or not I'd be
able to destroy them without burning my harddisk. I don't want to
wait a long time until my cipher is ready to encrypt or decrypt a
message, and I don't want to wait a long time until my computer
was able to do the encryption or decryption.
- I feel better if the cipher I've used was tested by good
cryptographers. Since I'm not very good in cryptanalysis I have to
hear what experts say.
Even on the AES candidates more cryptanalysis was done than on
SCOTTxxx, and these ones are by far too new to be used if security
is important.
Andreas Enterrottacher
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: Ruud de Rooij <*@spam.ruud.org>
Subject: Re: Compact Full-Keying Twofish Code?
Date: 15 Aug 1999 10:30:01 +0200
Reply-To: *@spam.ruud.org
[EMAIL PROTECTED] writes:
> Is there any clear (less obfuscated then the Twofish Teams code)
> implementation of a full-keying Twofish (ECB mode, cuz I can add CBC
> later).
>
> I would like code to just play with. I have read the Twofish Paper and
> well for my purposes I don't feel like coding it from scratch.
lsh (free ssh2 implementation) contains a full-keying Twofish
implementation. You can get lsh at
ftp://ftp.lysator.liu.se/pub/security/lsh/lsh-0.1.3.tar.gz
The twofish implementation is in src/symmetric/twofish.c
- Ruud de Rooij.
--
ruud de rooij | *@spam.ruud.org | http://ruud.org
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: NIST AES FInalists are....
Date: 15 Aug 99 12:23:32 GMT
Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
: [EMAIL PROTECTED] wrote:
: > BTW I seriously doubt in the 70's they had the ability to search the
: > DES keyspace in less then a year.
: You would lose your bet.
I remember a while ago, based on the success of the DES cracker built by
the EFF, doing a back-of-the-envelope calculation of what that might imply
for capabilities on the part of the NSA. Under assumptions which,
admittedly, were generous (assume no cost to make the machine flexible,
rather than fixed-purpose, assume the NSA has technologies 100 times more
efficient, assume the NSA can spend $25 billion as opposed to the $250,000
spent by the EFF, assume they can tie the machine up for 6 months or so on
a single problem) I noted that the success of the DES cracker implied that
even 80-bit keys could be within the reach of the NSA.
I recall some posters claiming that my estimate was preposterous.
(Considering what 6 months rent on a $25 billion machine would be, they
may have had a point, of course: even the NSA wouldn't bother cracking an
80-bit key just to read a typical user's E-mail under these assumptions.
Thus, it would be in error to conclude the NSA could read, say, _all_ the
E-mail traffic on the Internet if _everybody_ started using 80-bit keys.)
Now, the personal computers available nowadays are considerably improved
over what one could buy in 1979. But to suggest they are 16,000,000 times
faster (80-56 = 24) would perhaps be to overstate things. But by how much?
John Savard
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: New encryption algorithm
Date: Sun, 15 Aug 1999 13:17:28 GMT
M. K Shen wrote:
>As is also pointed out by the writer of another follow-up, you must
>lay open your algorithm if you intend to have it discussed in our
>group. I
don't think that there will be a single person of our group
>who will take the trouble to first sign an NDA with you and then
>start to examine your algorithm.
At this point of this new-algorithm-discussion I just have to
share with you my dillema:
It's no surprise that Tony Zelenoff was asked to reveal
his algorithm.
But lets theoretically assume that this algorithm really is
revolutionary and that its author would be able to make money on its
patent. In this case how can he insure his idea from being stolen by
somebody else who could simply patent it first and become the inventor
of
the algorithm in terms of law?
Please, share your opinion
Bartosz Zoltak
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
