Cryptography-Digest Digest #494, Volume #9 Mon, 3 May 99 14:13:03 EDT
Contents:
Re: mcrypt again ([EMAIL PROTECTED])
Re: Factoring breakthrough? (Reuben Sumner)
Re: Stream Ciphers and Quantum Computer Resistance (Tom Knight)
Re: True Randomness & The Law Of Large Numbers ("Tony T. Warnock")
Re: Stream Ciphers and Quantum Computer Resistance (SCOTT19U.ZIP_GUY)
SCOTT19U contest update (SCOTT19U.ZIP_GUY)
Re: Stream Ciphers and Quantum Computer Resistance (SCOTT19U.ZIP_GUY)
Re: Stream Ciphers and Quantum Computer Resistance (SCOTT19U.ZIP_GUY)
Re: Random Number Generator announced by Intel (Medical Electronics Lab)
Pentium3 serial number is based on who you [server/exterior] claimed to be (RD
OMeara)
Re: md5sum - improvement? (Bill Unruh)
Re: Adi Shamir ("Jung-Mok Hwang")
Public Key for Delphi, free ([EMAIL PROTECTED])
Re: Scramdisk/Norton query (Shaun Hollingworth)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: mcrypt again
Date: Mon, 03 May 1999 13:28:03 GMT
Try this C code snippet...
#define rol(x, y) ( (x << y) | (x >> (32 - y)) )
/* removes redundancy in a lossy delta prediction manner passwords are 16
chars long always!!! */ void passwd(char *passwd, unsigned long key[2]) {
int a;
key[0] = key[1] = 0;
/* mix in the 4 bit deltas */
key[1] = passwd[0] & 15;
for (a = 1; a < 16; a++)
key[a & 1] = (rol(key[a & 1], 4)) ^ ((passwd[a] - passwd[a - 1]) & 15);
/* perform data dependant rotations */
for (a = 0; passwd[a]; a++)
key[a & 1] = key[!(a & 1)] ^ rol(key[a & 1], ((passwd[a] - passwd[a - 1]) &
15));
}
The last line is rather wierd, but the for loop applies to the line(s). It
generates completely different outputs when one char is different. It will
suffice for passwd mushing I think. BTW, the output is 64 bits, but the
input must be 16 bytes, you can pad if you need to, but I wouldn't recommend
passwords under 16 bytes anyways.
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Reuben Sumner)
Subject: Re: Factoring breakthrough?
Date: 3 May 1999 12:05:32 GMT
Reply-To: [EMAIL PROTECTED]
On 29 Apr 1999 14:41:46 GMT, Steve Tate <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>> In article <[EMAIL PROTECTED]>,
>> lcs Mixmaster Remailer <[EMAIL PROTECTED]> wrote:
>> > Rumor has it Adi Shamir will announce factoring breakthrough soon.
>> > Increasing efficiency by orders of magnitude and breaking keys 100-200
>> > bits longer than current state of the art.
Well I can tell you that Prof Shamir did not drop any such hints in class
in the past two weeks when we covered factoring and discrete log. (he
described his power analysis key scheduling attack to us the same day he
was writing it up. "And here is something that I came up with yesterday...")
There is a NY Times article at
http://www.nytimes.com/library/tech/99/05/biztech/articles/02encr.html
It implies that special purpose hardware would be needed. I suspect
that means that the algorithm doesn't distribute particularly well and that
individual computing nodes need high bandwidth to the other nodes.
Reuben
------------------------------
From: Tom Knight <[EMAIL PROTECTED]>
Subject: Re: Stream Ciphers and Quantum Computer Resistance
Date: 03 May 1999 07:53:05 -0400
[EMAIL PROTECTED] () writes:
> Having noted that at least *one* view of quantum computers envisages them
> also incorporating reversible computation, in order that they can avoid
> catastrophic heat buildup while isolated,
*ALL* coherent quantum computers are reversible computers. The
erasure of information associated with irrevesibility forces
decoherence of the quantum state. So, if you are making use of the
fact that quantum computers are different from classical computers
(i.e. that they behave coherently) then the programs and algorithms
must necessarily be reversible.
> it occurs to me that one can certainly design a cipher so that it causes
> headaches for a reversible computer.
This might be right, and it's certainly an interesting direction to think in.
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Mon, 03 May 1999 08:14:59 -0600
Reply-To: [EMAIL PROTECTED]
"R. Knauer" wrote:
> On Sat, 01 May 1999 16:01:55 -0400, "Trevor Jackson, III"
> <[EMAIL PROTECTED]> wrote:
>
> >You have simply got to tell us where you get what you are smoking!
>
> I smoke Fellers and sometimes Li & Vitanyis and occasionally
> Kolmogorovs.
>
It would help if you would inhale.
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: Re: Stream Ciphers and Quantum Computer Resistance
Date: Mon, 03 May 1999 14:26:54 GMT
In article <7gi1na$5hv$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> >There are really two pratical ways to solve this problem
> > one is to use a true OTP ( One Time PAd) and the other is to use an
> > extremly high entropy system such as scott19u.zip where one uses a long
> > random file of ones choice and than a password to protect it. But even
> > then to be safe one should every so often change the long random key
> > file since if both the source code and long secrect key file is stolen
> > a quantum compter could be used to guess what password was used but it
> > is many orders of magnitude safer than any of the AES candidate types
> > with there small NSA friendly type of key lengths. But the trick is
> > to have the entropy high enough such that more than one solution exists
> > that way a quantum computer could never settle down on the correct
> > solution.
>
> You have never proved that compression and encryption can go hand in hand to
> make a safe cipher. You only conjectured that. In fact they are different
> fields so I don't know where they come in together...
>
Shanon proved many years ago that higher entropy systems are safer
if you don't belive that then use the NSA approved stuff. But compression
that has no headers can encrease the entropy per bit of the message. If
you can't understand that then I don't really care. But here is a sample
proof that may help you. If it does not help you then just wait for AES
and used what ever is blessed by the crypto gods.
Suspose I have 256 ascii messages which are of equal likely hood that
I want to send to friend I could use a cipher message like DEADFISH or
what ever. But the NSA may break it. Or I could compress it down to
one byte. Where each valule of the byte represents one of the ascii
messages. I then encrypt that one byte by using a single cyle S-table
of 8 bits by 8 bits. The key or S-table is very very small. But the
NSA can not break it since each message is likely.
> A real cryptosystem has a confusion sequence which hopefully is as random as
> the key. That is all you need for a cryptosystem.
You may be talking about methods that allow a random IV which could be
thought of as part of key. But if one uses the approved blessed FIPS
chaining methods the effect is for only a few blocks. I allow random
padding in my methods for scott16u and scott19u but I feel it best to
look at strenght before one adds such padding.
David A. Scott
--
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
to email me use address on WEB PAGE
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: SCOTT19U contest update
Date: Mon, 03 May 1999 15:11:26 GMT
I have just updated the next partial anwser to the contest.
Even someone with a 386 if he uses his brains can be the first
to crack the contest.
The contest is not the kind that could be run with weak AES
type of encryption systems. This is because they lack the all
or nothing nature of the fine scott19u cipher. The contest is
really just for an example and one can solve it by using a blind
search for the messing terms. Good Luck be the first and you can
gloat on my webpage.
David A. Scott
--
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
to email me use address on WEB PAGE
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: Re: Stream Ciphers and Quantum Computer Resistance
Date: Mon, 03 May 1999 14:48:21 GMT
In article <[EMAIL PROTECTED]>,
David Crick <[EMAIL PROTECTED]> wrote:
... most of his CRAP deleted
>
> "Besides a mathematical inclination, an exceptionally good mastery
> of one's native tongue is the most vital asset of a competent
> programmer."
> -- Edsger W.Dijkstra
I am glad you quoted the guy above. If he is what you think programming
is all about. Then you are well on the road to the great dumbing
down of America.
I am the kind of guy Youron and Dijkstra brain washed programmers call
when they actually want to cut throught the crap and get code to work.
Yes they like you dislike me. But there was a time in the government
when it was important to get code to work. But those days are rapidly
disappearing.
David A. Scott
--
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
to email me use address on WEB PAGE
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: Re: Stream Ciphers and Quantum Computer Resistance
Date: Mon, 03 May 1999 14:41:37 GMT
In article <7gj2tp$1b3o$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> writes:
> > Actually if one wants quantum computer resistance one should not be
> >so worried about reversiblity.
>
> Your ignorance is astonishing. Reversibility is very important since
> there is a space trade-off in making an irreversible algorithm reversible.
> This space trade-off could dramatically increase the number of quantum
> bits and gates necessary to impliment an algorithm on a quantum computer
> and could thereby hinder the ability to crack an algorithm on a
> quantum computer.
>
I guess a simple proof that some one of your limited mentaly ability
could under stand is this. If one encrypted with a incredable complex
method that only had a key of 2 bits. Then the quantum compter needs
to only test 4 cases max no matter how comples the encryption was.
It is the entropy that is the main key to preventing quantum computers
of the future from being able to be CRACKED period. Or is this over your
head?
> > But one should worry more about the
> >overall entropy of the system. If one is limited by using a weak method
> >such as any of the AES canditates likely to be blessed by the NSA and
> >if one is sending ascii messaages of a few dozen characters or more
> >then quantum computers will be able to solve for the likely unique
> >solution.
>
> Oh really? Give us a proof.
I did but it may be to complex for you.
>
> >There are really two pratical ways to solve this problem
> >one is to use a true OTP ( One Time PAd) and the other is to use an
> >extremly high entropy system such as scott19u.zip where one uses a long
> >random file of ones choice and than a password to protect it. But even
> >then to be safe one should every so often change the long random key
> >file since if both the source code and long secrect key file is stolen
> >a quantum compter could be used to guess what password was used but it
> >is many orders of magnitude safer than any of the AES candidate types
> >with there small NSA friendly type of key lengths. But the trick is
> >to have the entropy high enough such that more than one solution exists
> >that way a quantum computer could never settle down on the correct
> >solution.
>
> Quantum computers do not "settle down" on the correct solution. And I'm
> not aware of an analysis of an extension of the quantum search algorithm
> to the case where there is more than one solution -- if you have one and
> it shows that it dramatically decreases the effectiveness of the quantum
> search algorithm, then I suggest that you post your reference.
>
If you read some of the literature from 1997 you can see that the
advantage of quantum compters is that they can try more than one
solution at a time. I word things the way I want to if you want to
word differently do so. But only a fool would think that research
since then has not gone BLACK and that the NSA does not already have
very cool quatum compters that you may lack the mental ability to
understand. That is why the key to future encryption methods should
greatly consider entropy as a major part of the design. So that there
is enough entropy in messages so that many keys can decrypt
to more than one message. Thus making it unlikely that a gussessed
key even if it gives a correct looking message would actually be the
right message.
David A. Scott
--
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
to email me use address on WEB PAGE
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Random Number Generator announced by Intel
Date: Mon, 03 May 1999 12:34:02 -0500
[EMAIL PROTECTED] wrote:
>
> A recent quote from some Russian "Rocket Scientists" turned commercial
> software developers. "Rocket science is nothing, all you need is a
> container with one end cut off and an explosion."
>
> Hey, they said it not me! They have a great additude about the
> changes in the former Soviet Union. Oh and if you can spec it, they
> can write it.
I agree with that! I always say it's easy: Newtonian mechanincs
and plumbing. I like the Russian version better tho :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (RD OMeara)
Crossposted-To: alt.security
Subject: Pentium3 serial number is based on who you [server/exterior] claimed to be
Date: Mon, 03 May 1999 12:00:01 -0500
> Very robust! and usable for a pgp type handshake(s) ?
-- Greetings from me.ro (RD OMeara )
From: EE Times <[EMAIL PROTECTED]>
Date: Sun, 2 May 1999 07:33:09 -0700 (PDT)
Pentium ID concerns were unfounded, expert says
http://www.eet.com/story/OEG19990127S0011
SANTA CLARA, Calif. — Concerns that the indentification number
Intel Corp. has put on Pentium III processors could have been used to
track Web activity might have been overstated, as Intel's ID
mechanism masks the ID number from any Web site requesting it,
according to a security expert who has worked with Intel.
In fact, any two Web sites verifying the number will get different
results, making it almost impossible to correlate their visitor
lists. The ID mechanism also would have operated outside of Windows
by using a proprietary software agent that was intended to prevent
"spoofing" of the ID number.
This approach makes the ID number far more complex than a car's
license plate or vehicle ID number. "The processor number says if you
write down my license plate number and someone else does, they'll be
different numbers," said Shawn Abbott, chief technology officer at
Rainbow Technologies Inc. (Irvine, Calif.).
These factors might mitigate the concerns of privacy groups such as
the Electronic Privacy Information Center (Epic; Washington), which
declared a boycott of Intel products over the ID numbers in Pentium
IIIs. Intel subsequently withdrew plans to include the ID number in
response to those concerns. Epic and others feared that the ID number
could have been used for surveillance of consumer Web surfing;
another common concern was that the ID number could be easily faked
in software, rendering the concept useless.
Technology to keep the ID number blinded was developed by Rainbow for
its own hardware "dongles," which for years have been sold to
corporations for PC security. Intel approached Rainbow last year to
develop the security setup for the ID number.
"Very early on, when Intel described it, they were very, very careful
to address certain concerns," Abbott said. The final scheme was
defined after deep scrutiny by Intel and Rainbow, addressing problems
such as traceability on the Web, he said.
Under Intel's scheme, every Web server has a unique, randomized ID
number that's transmitted along with a request to verify a PC's ID
number. At this point, a trusted agent intercepts the request and
submits it to the microprocessor.
The agent then takes the Web and Pentium numbers, runs a complex set
of calculations, and returns a third number, which is uploaded to the
server.
It's this third number that is used to identify that particular
Pentium. The process will return the same number every time that
particular machine accesses the server in question, verifying the
machine's identity.
But because every Web server has a different ID, the hashed number
uploaded from the PC will differ from one site to the next. No site
will know the Pentium's actual ID number, nor will any two servers
use the same hashed number to represent a particular Pentium.
The setup also prevents "spoofing" of the serial number, another fear
among privacy advocates. The agent that intercepts the ID request is
an example of "tamper-resistant software," which is difficult to
replicate or alter and manages to tap the processor ID number without
divulging the number to the outside.
Tamper-resistant software is a "black art," Abbott said, and several
companies in the security industry have tried their hand at it.
"Think of them [tamper-resistant agents] as armor around something.
They can always be taken apart and defeated, but the effort becomes
too much," he said.
Intel was unavailable for comment late Tuesday.
For more technology news, visit http://www.eet.com
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: md5sum - improvement?
Date: 3 May 1999 17:25:03 GMT
In <7gjid7$hud$[EMAIL PROTECTED]> [EMAIL PROTECTED] (J.H.M. Dassen (Ray))
writes:
>Herwig Huener & Josella Simone Playton <[EMAIL PROTECTED]> wrote:
>>(1) Are there two strings of non-zero-length and not equal to each other
>>known to mankind, which have the same MD5-checksum (or "fingerprint")?
>The capability of efficiently generating another string with the same
>MD5-checksum as a given string would make MD5 useless.
ALL hash functions are many to one maps, and thus there are infinite
numbe of strings with the same MD5 hash. This is an inescapable feature
of a hash function and cannot be improved. However a good hash is one
where it is very very difficulty to find another string which hashes to
the same value as the given string.
------------------------------
From: "Jung-Mok Hwang" <[EMAIL PROTECTED]>
Crossposted-To: de.org.ccc
Subject: Re: Adi Shamir
Date: Mon, 3 May 1999 19:55:14 +0200
Oops.....sorry.....
didnt saw the threats written before...
-Jung-Mok
------------------------------
From: [EMAIL PROTECTED]
Subject: Public Key for Delphi, free
Date: Mon, 03 May 1999 18:15:13 -0400
Introducing FGInt, successor of GInt and at least 10 times faster,
performs RSA, ElGamal Encryption & Signing and DSA and GOSTDSA signing
in no time. All this for free and with source code.
Available at
http://ace.ulyssis.student.kuleuven.ac.be/~triade
------------------------------
From: [EMAIL PROTECTED] (Shaun Hollingworth)
Subject: Re: Scramdisk/Norton query
Date: 3 May 1999 12:17:02 -0500
On Fri, 23 Apr 1999 23:44:45 GMT, "N" <[EMAIL PROTECTED]> wrote:
>Can anyone tell me why deleted files with an SVL extension keep appearing in
>my Norton protected recycle bin, even though no container files have been
>loaded or deleted and the Scramdisk utility program has not been running?
>
>When I remove them from the bin, they always reappear, often within minutes!
>They normally have a name such as 00000011.svl or 00007337.svl, for example,
>and range in size from 20K to 200Mb! I have tried excluding this file
>extension from Norton Protection, but to no avail. Norton cannot identify
>which program deleted them, but since the Scramdisk utility program isn't
>running presumably it must be work of the driver SD.VXD?
>
The driver protects the deletion of SVL files.
It does not protect the renaming, so you can either:
1: Run the Scramdisk exe and click on allow deletetion of SVL files in
config. This is just set temporaily.
2: Rename the files something other than .SVL and then delete them
Windows gives an error box if you use explorer to try and delete them.
Perhaps you are using another program that assumes you can never get
an error from delete.......
Regards,
Shaun.
>It does seem to be a gross waste of space for spurious files as large as
>200Mb to be taking up this kind of space continually!
>
>Thanks
>N
>
>
>
>
>
>
------------------------------
** 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
******************************
