Cryptography-Digest Digest #495, Volume #10 Tue, 2 Nov 99 15:13:04 EST
Contents:
Re: need LFSR information ("T.Williams")
Idea for Twofish and MARS ([EMAIL PROTECTED])
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
([EMAIL PROTECTED])
Re: What is the deal with passwords? (Anton Stiglic)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column ("Trevor
Jackson, III")
Re: Bruce Schneier's Crypto Comments on Slashdot (SCOTT19U.ZIP_GUY)
Re: What is the deal with passwords? (Tom St Denis)
Re: What is the deal with passwords? (Tom St Denis)
Re: Steganography Academy (SCOTT19U.ZIP_GUY)
Re: need LFSR information (Scott Nelson)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
(SCOTT19U.ZIP_GUY)
Q: metric of sieving efficiency in NFS (Francois Grieu)
Re: the ACM full of Dolts? (Mok-Kong Shen)
----------------------------------------------------------------------------
From: "T.Williams" <[EMAIL PROTECTED]>
Subject: Re: need LFSR information
Date: Tue, 02 Nov 1999 15:16:42 +0000
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Scott Nelson wrote:
<blockquote TYPE=CITE>On 15 Oct 1999, "Trevor Jackson, III" <[EMAIL PROTECTED]>
wrote:
<p>>Scott Nelson wrote:
<br>>> I wrote a program to calculate maximal length LFSR's,
<br>>> using "that chordic nonsense." After 32 bits, it
<br>>> can only find "probable" polys. The list of Probable
<br>>> polys include all maximal length LFSR's but might include
<br>>> a few less-than maximal length polys as well.
<br>>>
<br>>> Hardly the best way to find LFSR's, but it's faster than
<br>>> straight out brute force, and the code's already done.
<br>>> On my Pentium 166, it takes 23 seconds to find all 16 bit LFSR's.
<br>>>
<br>>> For those interested, there's a copy (with source) on my ftp site
<br>>> <a
href="ftp://helsbreth.org/pub/helsbret/random">ftp://helsbreth.org/pub/helsbret/random</a>
<br>>
<br>>The site has not been available. I've tried several times over
the last
<br>>~18 hours.
<br>>
<br>I've just updated the program to include all the factors of the
<br>Mersene numbers 2^512-1 or less. For those numbers
<br>(and of course the Mersene primes 521, and 607)
<br>it now proves the polys are maximal. LFSR's larger than 512
<br>are still only "probable."
<p>There's also a striped down version (lfsr_s) which only works
<br>up to <sizeof(long) in bits> but should be easier to understand
<br>and/or port to other machines, and it's faster.
<p>I've also added the search method "once" and fixed the "start at"
<br>feature, so it can now reasonably be used to test existing polys.
<p>I've re-tested all the polys in the first edition
<br>Applied Cryptography and only the ones I listed before we're bad.
<br>(For those few who care, the bad ones are;
<br>33,16,4,1,0 - should be 33,6,4,1,0
<br>82,41,8,7,6,0 - should be 82,41,8,7,6,4,0
<br>98,7,4,3,1,0 - should be 98,7,4,3,2,1,0 or 98,27,0
<br>119,45,0 - should be 119,8,0 or 119,38,0
<br>172,2,0 - should be 172,7,0 )
<p>Scott Nelson <[EMAIL PROTECTED]></blockquote>
Where might one locate the "bnum" library required by LFSR.C ? Thanks.</html>
------------------------------
From: [EMAIL PROTECTED]
Subject: Idea for Twofish and MARS
Date: Tue, 02 Nov 1999 15:00:07 GMT
One of the main features of DES was that certain bits affected more than
one s-box selection. After looking at TwoFish and MARS again last
night, I came up with an idea that could improve them.
Twofish has a G function which consists of two F-functions, and PHT, and
the addition of two round subkeys. Before the plaintexts are passed
through the F-functions, one of them is rotated by 8 bits. I was
thinking that if the inputs to both F-functions were rotated by 4 bits,
one left and one right for instance, the output of each s-box would be
affected by two inputs.
For MARS, the s-boxes are used mainly during forwards and backwards
phases of mixing. If all of the plaintexts were rotated by 4 bits
before the forwards and backwards mixing, wouldn't this also increase
the avalanche affect?
Anyway, these are just idea I came up with. It just seemed that nobody
was doing anything like this. The only reason I picked 4 for the
rotates was that you would have 1/2 of each of two bytes determining the
output of an 8xN (or in MARS, 9x32) s-box.
csybrandy.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 02 Nov 1999 15:51:58 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Stefek Zaba) wrote:
>The ciphersuite negotiation has been simplified from the
>SSL2.0 days: it's now as brutal as: initiator (client) sends ordered
>list (which, to David W's point later in the message excerpted above,
>had better contain ONLY algorithms the client considers adequate for
>its interaction); responder (server) picks exactly one, or aborts.
>There is *no* renegotiation or independent negotiation of particular
>attributes - cihpersuites come as a particular package of <key-
>agreement, bulk-cipher, MAC>. And the negotiation messages are
>themselves MAC'ed, defeating the simple active attack which SSLv2 was
>open to. Protection against protocol version rollback attack is also
>incorporated.
In another message (see:
http://www.deja.com/threadmsg_ct.xp?AN=540914195" ) I suggested to send
a list of only *one* ciphersuite, i.e. not to send a list at all. If I
send a message containing my information, it should be I who defines
how to encrypt it - not the other party in some way. Security should
not be negotiable.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: What is the deal with passwords?
Date: Tue, 02 Nov 1999 11:15:05 -0500
Tom St Denis wrote:
>
> Encryption of your key requires a very high entropy password. Most
> people would use 'house' over '!@af331B%1%' so I don't really see a
> security benefit other then making it a tad harder to attack. If you
> don't have access to the keyring at all I think that makes it much
> harder to attack.
Well you could simply use key stretching then!
See the article from Kelsey, Schneier, Hall and Wagner,
"Secure Applications of Low-Entropy Keys". This was exactly made
for that!
------------------------------
Date: Tue, 02 Nov 1999 11:49:41 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Stefek Zaba) wrote:
>
> >The ciphersuite negotiation has been simplified from the
> >SSL2.0 days: it's now as brutal as: initiator (client) sends ordered
> >list (which, to David W's point later in the message excerpted above,
> >had better contain ONLY algorithms the client considers adequate for
> >its interaction); responder (server) picks exactly one, or aborts.
> >There is *no* renegotiation or independent negotiation of particular
> >attributes - cihpersuites come as a particular package of <key-
> >agreement, bulk-cipher, MAC>. And the negotiation messages are
> >themselves MAC'ed, defeating the simple active attack which SSLv2 was
> >open to. Protection against protocol version rollback attack is also
> >incorporated.
>
> In another message (see:
> http://www.deja.com/threadmsg_ct.xp?AN=540914195" ) I suggested to send
> a list of only *one* ciphersuite, i.e. not to send a list at all. If I
> send a message containing my information, it should be I who defines
> how to encrypt it - not the other party in some way. Security should
> not be negotiable.
Why do you care? If you choose a set of ciphers in which you trust you
*are* defining how to encrypt your information.
If you are stuck at 3DES and the other person insists upon AES_1, will you
prefer to not communicate rather than communicate with a cipher other than
your favorite?
Do you also have a preference for particular keys?
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Bruce Schneier's Crypto Comments on Slashdot
Date: Tue, 02 Nov 1999 17:51:08 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>"Patrik J�rnefelt" wrote:
>> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) writes:
>> > I did write to the NSA about a job a few years ago but the Bastards
>> > never even wrote back.
>> Ahh.. suddenly it all makes sense.
>
>I bet he didn't even file a SF 171, because he's so special that
>he doesn't have to cooperate with established procedures.
That is an old form no longer in use. But I never got any awnser
back so it never progressed to that stage. had they wanted a SF 171
they had access to it if they want to look. I suspose as contriversal
that I am they all ready had it.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What is the deal with passwords?
Date: Tue, 02 Nov 1999 17:06:30 GMT
In article <[EMAIL PROTECTED]>,
John Kennedy <[EMAIL PROTECTED]> wrote:
> High entropy pass phrases are not as difficult to memorize as most
> people seem to think. Most people can rememeber some fairly long
> sentences. String a few sizable sentence fragments toghether, mangle
> them a bit in a non obvious way, and you've got a high entropy pass
> phrase. You can now use this to protect a lot of high entrpy passwords
> of the type you described, and you don't have to remember them. There
> are well documented memorization techniques that you can use to
> memorize the state capitals or periodic table in a short time if you
> really want to. You can memorize a high entropy pass phrase.
>
> Most people are perfectly cpable of doing this. Most people don't want
> to. That's fine, they can do it if they feel the need. I have no
> objection to unencypted keys for many purposes.
While you have a valid point, the average joe blow user will a) not
know what a good password is and b) not want to memorize it. I don't
think I could memorize a2AS21vhy65$1! for more then a day or two before
it fades...
Also an important note is you don't have access to my private exponent
(key) anyways to make encrypting it worth while. I can put it on a
floppy to hide it from my parents.... Not too hard. Plus a bonus
feature is I can take it to school and use it there..
Thanks for the input,
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What is the deal with passwords?
Date: Tue, 02 Nov 1999 17:11:41 GMT
In article <[EMAIL PROTECTED]>,
John Kennedy <[EMAIL PROTECTED]> wrote:
> I don't know about innovative. You could easily "cripple" PGP to work
> this way. PeekBoo just forgoes a customary security measure.
Sure cripple... hmm tell me. How would you get my private key from me
anyways? What requirement is there for encrypting something YOU DON'T
HAVE ACCESS to anyways?
> >This is why Peekboo is 41kb and PGP is 7500kb ...
>
> No, I'm sure that's not why.The reason has nothing to do with
> encrypted keys. And if PeekBoo professes to have all its advertized
> compression technology in 41k it might be snake oil after all.
First I thought you were rude, now you are just an ass. The executable
is really 105kb or so, I just compressed it so it's smaller for
transport. See I put a thought together and figured that I could save
time and space this way. There is nothing saying PGP could not do the
same. They just didn't. The source is online, so if you want to
spread lies about it, read the source first [and hopefully you won't
spread lies afterwards]. Otherwise keep shut.
btw when I said 41kb vs 7500kb I am talking about alot of extra things
they don't need todo. I would admit I should add file encryption to
peekboo, but that doesn't have to make it 7mb in size...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Steganography Academy
Date: Tue, 02 Nov 1999 18:14:36 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(John Savard) wrote:
>korejwa <[EMAIL PROTECTED]> wrote, in part:
>
>>I'm sure most of you are familliar with Fravia's pages of Reverse
>>Engineering. Perhaps you are also familliar with Fravia's Steganography
>>Academy. I can't tell you the disapointment I felt after I reversed
>>Fravia's images, only to find out that Fravia has 'retired', and his
>>Steganography Academy seemingly no longer exists.
>
>Although www.fravia.org doesn't work anymore, many of the mirrors of
>his page are still around, such as:
>
>http://www.phase-one.com.au/fravia/index.html
>
>John Savard ( teneerf<- )
>http://www.ecn.ab.ca/~jsavard/crypto.htm
I am sorry to hear Mr Fravia has 'retired'. Does this mean he
was murdered or what? He at one time promised his readers he would
break the scott16u contest. I hope my encryption which is orders of
magnitude stronger than the weak short keyed methods of the AES
compitation did not casue a mental break down or something.
I wish I could have meet him he was fighting an uphill and I am sure
that it was possibly various government agencies may have made is
life a livinghell. People in government tend to hate talented free thinkers
like Mr Fravia.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: need LFSR information
Reply-To: [EMAIL PROTECTED]
Date: Tue, 02 Nov 1999 17:37:48 GMT
On Tue, 02 Nov 1999 15:16:42 +0000, "T.Williams"
<[EMAIL PROTECTED]> wrote:
>Scott Nelson wrote:
><blockquote TYPE=CITE>On 15 Oct 1999, "Trevor Jackson, III" <[EMAIL PROTECTED]>
>wrote:
><p>>Scott Nelson wrote:
><br>>> I wrote a program to calculate maximal length LFSR's,
><br>>> using "that chordic nonsense." After 32 bits, it
><br>>> can only find "probable" polys. The list of Probable
><br>>> polys include all maximal length LFSR's but might include
><br>>> a few less-than maximal length polys as well.
><br>>>
><br>>> Hardly the best way to find LFSR's, but it's faster than
><br>>> straight out brute force, and the code's already done.
><br>>> On my Pentium 166, it takes 23 seconds to find all 16 bit LFSR's.
><br>>>
><br>>> For those interested, there's a copy (with source) on my ftp site
><br>>> <a
>href="ftp://helsbreth.org/pub/helsbret/random">ftp://helsbreth.org/pub/helsbret/random</a>
><br>>
><br>>The site has not been available. I've tried several times over
>the last
><br>>~18 hours.
><br>>
><br>I've just updated the program to include all the factors of the
><br>Mersene numbers 2^512-1 or less. For those numbers
><br>(and of course the Mersene primes 521, and 607)
><br>it now proves the polys are maximal. LFSR's larger than 512
><br>are still only "probable."
><p>There's also a striped down version (lfsr_s) which only works
><br>up to <sizeof(long) in bits> but should be easier to understand
><br>and/or port to other machines, and it's faster.
><p>I've also added the search method "once" and fixed the "start at"
><br>feature, so it can now reasonably be used to test existing polys.
><p>I've re-tested all the polys in the first edition
><br>Applied Cryptography and only the ones I listed before we're bad.
><br>(For those few who care, the bad ones are;
><br>33,16,4,1,0 - should be 33,6,4,1,0
><br>82,41,8,7,6,0 - should be 82,41,8,7,6,4,0
><br>98,7,4,3,1,0 - should be 98,7,4,3,2,1,0 or 98,27,0
><br>119,45,0 - should be 119,8,0 or 119,38,0
><br>172,2,0 - should be 172,7,0 )
><p>Scott Nelson <[EMAIL PROTECTED]></blockquote>
>Where might one locate the "bnum" library required by LFSR.C ? Thanks.</html>
I suspect what you really want is the file "mnumbers.h",
which I inadvertantly left out of the zip archive lfsr_src.zip
and without which you can not compile lfsr.c
Sorry about that. It should be in the archive now.
The relevant portions of the bnum package are included in
the file lfsr.c, between lines 148 and 460.
If you really want the whole bnum package, contact me via email.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 02 Nov 1999 18:56:23 GMT
In article <[EMAIL PROTECTED]>, "Trevor Jackson, III" <[EMAIL PROTECTED]>
wrote:
>[EMAIL PROTECTED] wrote:
>
>> In article <[EMAIL PROTECTED]>,
>> [EMAIL PROTECTED] (Stefek Zaba) wrote:
>>
>> >The ciphersuite negotiation has been simplified from the
>> >SSL2.0 days: it's now as brutal as: initiator (client) sends ordered
>> >list (which, to David W's point later in the message excerpted above,
>> >had better contain ONLY algorithms the client considers adequate for
>> >its interaction); responder (server) picks exactly one, or aborts.
>> >There is *no* renegotiation or independent negotiation of particular
>> >attributes - cihpersuites come as a particular package of <key-
>> >agreement, bulk-cipher, MAC>. And the negotiation messages are
>> >themselves MAC'ed, defeating the simple active attack which SSLv2 was
>> >open to. Protection against protocol version rollback attack is also
>> >incorporated.
>>
>> In another message (see:
>> http://www.deja.com/threadmsg_ct.xp?AN=540914195" ) I suggested to send
>> a list of only *one* ciphersuite, i.e. not to send a list at all. If I
>> send a message containing my information, it should be I who defines
>> how to encrypt it - not the other party in some way. Security should
>> not be negotiable.
>
>Why do you care? If you choose a set of ciphers in which you trust you
>*are* defining how to encrypt your information.
>
>If you are stuck at 3DES and the other person insists upon AES_1, will you
>prefer to not communicate rather than communicate with a cipher other than
>your favorite?
>
>Do you also have a preference for particular keys?
>
>
I know I am getting in this late but if one person has his heart set on
3DES and another AES_! why not allow them to use both in series so
that both methods can be used at once.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (Francois Grieu)
Subject: Q: metric of sieving efficiency in NFS
Date: Tue, 02 Nov 1999 19:19:38 +0100
I am in search of a standard quantity measuring the efficiency
of a sieving implementation, as arising in efforts with the
Number Field Sieve.
Ideally the quantity should measure usefullness of the sieving
work done from the point of view the underlying factor algorithm.
I can think of the number of additions per second.
Or, probably more usefull, the amount of log(p) added per second,
in base 2 maybe. Or idealy some quantity better measuring the
usefullness, which may grow faster than log(p).
Is there an accepted standard ? Any reference ? Any data to
compare against ? A standard factor base for benchmarks ?
It's not trivial what the distribution of the factors should be,
even less what are reasonable values for the smallest and highest
factors !
Thanks in advance,
Francois Grieu
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: the ACM full of Dolts?
Date: Tue, 02 Nov 1999 19:20:40 +0100
SCOTT19U.ZIP_GUY wrote:
>
an.
> >
> by normal adaptive Huffman I meant the one like I modifed to get mine
> to work. If you just stated with secrect infomation till so the last token
> ended on a byte boundary. You could use the rest of the file for your
> real message and only send that part.
> But it would add info to the file. Granted since the front part of file is
> missing and you have added encryption. But info is still added that
> would not be there if you used my method of compression.
The user can either set the frequency counts at the start of the
algorithm or prime the algorithm with a piece of selected text. Both
can be done, but the first seems to be more versatile and
straightforward.
I think I now understand what you mean by 'info is added', namely
the 'addition' of the 'effective bits' contained in the chosen
initial distribution. (I thought you meant that the file would be
rendered longer by a certain amount due to that.) Yes, it is not
always very convenient/practical to have to employ additional secrect
informations beyond the key for the proper encryption algorithm
for sending messages.
M. K. Shen
------------------------------
** 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
******************************
