Cryptography-Digest Digest #502, Volume #10 Wed, 3 Nov 99 16:13:03 EST
Contents:
Re: Build your own one-on-one compressor (Tim Tyler)
Re: Build your own one-on-one compressor (Tim Tyler)
Re: Scientific Progress and the NSA (was: Bruce Schneier's Crypto Comments...)
(wtshaw)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Scott Nelson)
Re: IBM 4758 (was: CA software) (Peter Pearson)
Re: Incompatible algorithms (wtshaw)
Re: Q: Removal of bias (wtshaw)
Re: Q: Removal of bias (Scott Nelson)
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("Tony T. Warnock")
Re: What is the deal with passwords? (Johnny Bravo)
Re: crypto and dependencies (John Savard)
Re: cryptohoping (John Savard)
Re: Proposal: Inexpensive Method of "True Random Data" Generation
([EMAIL PROTECTED])
Re: unpacker to trace code (JPeschel)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (John Savard)
Re: Q: Removal of bias (Tom St Denis)
Re: What is the deal with passwords? (Tom St Denis)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (John
Savard)
----------------------------------------------------------------------------
Crossposted-To: comp.compression
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Build your own one-on-one compressor
Reply-To: [EMAIL PROTECTED]
Date: Wed, 3 Nov 1999 17:10:20 GMT
In sci.crypt Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> However, I am happy to try to look at things using your terms. If your
:> algorithm looks up "side2" entries in your dictionary and replaces them by
:> the equivalent "side1" entry (when decompressing - and does the reverse
:> when compressing), then your dictionary *must* have each entry
:> twice, with the second lot of entries reversed (as follows):
:>
:> Side1 Side 2
:> ABCD <-- HG
:> HTHN <-- UK
:> XYZ <-- PQ
:>
:> HG <-- ABCD
:> UK <-- HTHN
:> PQ <-- XYZ
:>
:> If you fail to do this your system is unlikely to work.
: Why on earth MUST a dictionary be of this form (every entry on
: one side is also present on the other)?
It's a specified part of my scheme. If you translate "ABCD" to
"XYZ", you *must* simultaneously replace any occurrences of
"XYZ" with "ABCD" - or the whole system I am proposing will fail to
work.
: Have you ever seen an English-French dictionary like that?
No. My proposal bears little relation to an English-French dictionary.
: Note that you have yourself given an example where on the left side
: (my side1) are English alphabets and on the right side (my side2) you
: exclusively use /, [, etc. Why MUST your dictionary not ALSO be of
: this nature?
In that scheme I believe I interposed double-ended arrows between the
dictionary entries (thus: "<-->") in an attempt to indicate the
replacement occurred in both directions.
If I were to translate this dictionary into your "side1"/"side2" notation,
where compression maps "side2" entries to "side1" ones and decompression
does the reverse, I *would* need to duplicate all the dictionary entries
before the scheme is guaranteed to function correctly.
: Quite evidently, there are currently much misunderstanding between
: us. For example, I took the verbatim copying rule out of a follow-up
: from Scott where he commented on my example. But this you told me is
: non-existent in your scheme.
What you should never do with my scheme is take a dictionary
*without* repeated, reversed entries, and fail to map occurrences of
"side1" strings to their "side2" equivalents (as well as mapping "side2"
strings to their "side1" equivalents).
: Now, to be able to properly do further arguments and not waste
: unnecessary time and effort because of differences in definitions etc.,
: I like to propose that some fundamental stuffs be thoroughly cleared up.
: Let me ask you therefore a few questions (allow me for simplicity to
: continue to use side1 to denote the uncompressed side and side2 to denote
: the compressed side):
This notation seems to be a source of confusion in itself.
However, I will continue to use it in this dialogue.
: (1) Must the symbol sets that appear on both sides of a dictionary
: be identical? (I presume not. See your own example.)
Yes. If you have a dictionary entry:
"ABCD" <-- "XYZ"
...you *must* also have:
"XYZ" <-- "ABCD"
One dictionary I gave did not have this property - as I was not using your
"side1", "side2" notation when I gave it.
Using your notation doubles my typing, and apparently introduces a
(non-existent) distinction between compression and decompression, without
producing any benefit, IMO.
In my scheme compression is simply a case of applying the same
transformation to the text again.
: (2) If the answer to (1) is no, what does one do in case (when
: translating a string from side2 to side1) one encounters
: (unexpectedly) a symbol that only appears on side1 of the
: dictionary? (Should one do a verbatim copying, issue an error
: message to the user, or what?)
Answer to (1) is yes. I skip this question.
: (3) MUST a dictionary have the form above or not?
In your "side1", "side2" notation - yes. If it does not, the system will
probably fail to work.
: Besides the two criteria that you gave in an earlier post, namely
: No string in the tables should contain another such string
: as a substring.
:
: No leading symbols in any string should exactly match the
: trailing symbols in a different string.
: what else exactly must a dictionary also satisfy?
These are the only conditions for the dictionary in my original format.
If you use your own "side1", "side2" notation, each dictionary
entry should be present with the sides reversed - and note that the above
two conditions need only be applied to the entries on one side of the
dictionary, if using your notation.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Very funny Scotty. Now beam down my clothes.
------------------------------
Crossposted-To: comp.compression
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Build your own one-on-one compressor
Reply-To: [EMAIL PROTECTED]
Date: Wed, 3 Nov 1999 17:14:21 GMT
In sci.crypt Don Taylor <[EMAIL PROTECTED]> wrote:
: Would someone be nice enough to post a chosen alphabet, a current set
: of rules for using the dictionary, and a dictionary that is thought
: to be correct AND that does exhibit some degree of compression for
: a variety of, yet unknown, sentences that would then be tried against
: this dictionary?
Can you get to my monograph at http://www.alife.co.uk/securecompress/ ?
This contains a (small) sample dictionary which would be of some use for
compresing test messages, together with a description of the algorithm
which performs the string substitutions.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Always remember you're unique, just like everyone else.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Scientific Progress and the NSA (was: Bruce Schneier's Crypto Comments...)
Date: Wed, 03 Nov 1999 11:31:42 -0600
In article <7vokc4$1mpa$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
>...Where the HELL was the NSA when our nuclear
> screts were giving to CHINA or did Clinton order than to
> not look.
>
It makes you wonder whether they are just stupid, they think Clinton is
too stupid to be trusted with such information, whether they are playing
some sort of game(at what greater importance?), or if politicians think
reality can be totally managed.
Our countries priorities are pretty clear to me, and it does not include
blind trading with ideological enemies in the nuclear arena, or upsidedown
favorable treatment of things preached to be restricted to out real
friends, including crypto.
--
Those who think that all useful encryption is done in binary
are destined to be thought of as mere bit-players.
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Reply-To: [EMAIL PROTECTED]
Date: Wed, 03 Nov 1999 17:30:12 GMT
On 3 Nov 1999 08:33:45 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>In article <[EMAIL PROTECTED]>,
>Tony T. Warnock <[EMAIL PROTECTED]> wrote:
>>Uncle Al wrote:
>>
>>> The digits of pi are purely random (except for being pi). We've got
>>> pi to about 50 billion decimal places. Nobody would suspect using the
>>> digits of pi becaise it is not a random number. No problem. Use pi.
>>
>>I would like some reference to this. As far as I know, no one has proved
>>that the digits of pi are purely random, quasi random, non random,
>>uniformly distributed, etc.
>
>I believe pi has been proved "normal", which is to say that every
>finite-length string appears equiprobably in the extended decimal
>expansion. In point of fact, I think it's been proved "normal to
>all bases," which means the same holds in the octal, hexadecimal,
>binary, septal, &c. expansions.
>
>Not that this necessarily means much w.r.t "randomness" as
>0.12345678910111213.... is also "normal," at least to base 10, and
>I believe to all bases.
>
>And, no, I don't have a reference offhand, but it should be addressed
>in a decent analysis text.
>
> -kitten
All the numbers might appear in the decimal expansion of PI,
but they aren't equiprobable. Long runs of zeros can't occur
early, so their probability is lower. Other repeating patterns
are also impossible in early positions. Thus, PI has been
proved to be "non-normal" although the bias is so slight
that only a mathematician would make the distinction.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: Peter Pearson <[EMAIL PROTECTED]>
Subject: Re: IBM 4758 (was: CA software)
Date: Wed, 03 Nov 1999 09:33:10 -0800
Paul Rubin wrote:
>
> Shawn Willden <[EMAIL PROTECTED]> wrote:
> >IBM's Trust Authority and Vault Registry products provide this,
> >although it could be a little more turnkey. The tamper-resistant
> >(actually tamper-reactive) hardware is an IBM 4758 PCI Cryptographic
> >Coprocessor. It is FIPS 140-1 certified, currently to level 4, soon
> >to level 3. See IBM Cryptography: 4758 PCI Cryptographic Coprocessor
> >technical description for details of the 4758. See Security :
> >Products for info about more IBM security products.
>
[snip]
>
> What is this though about it being soon to be certified only to level 3?
> Is it losing its level 4 certification for some reason?! Or are they
> coming out with an "economy model" that's only at level 3, or relaxing
> some of the interlocks or something like that? You've got me wondering
> now.
I've been heavily involved with the 4758 for the past several
months. The failure rate has been staggering, and seems to result
from false alarms from the tamper-detection system. ("We're being
attacked! Take your cyanide pill!") Boards that fail this way
must be replaced. A sensible move by IBM would
be to produce a less paranoid version that would trade lowered
tamper resistance for improved reliability.
- Peter
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Incompatible algorithms
Date: Wed, 03 Nov 1999 11:57:49 -0600
In article <[EMAIL PROTECTED]>, Max Polk
<[EMAIL PROTECTED]> wrote:
> I have a question about the existance of what I call "incompatible"
> algorithms.
>
....
>
> Any attempt to break a chain of such "incompatible" algorithms then grows
> in order of magnitude at each step to such a degree of complexity as to
> make the ciphertext arbitrarily secure.
>
> If this is all true, it may be possible to make the time complexity of
> breaking the ciphertext 10 to the power of n where n equals the number of
> steps in the chain.
>
> In this case, each additional algorithm applied makes the solution grow
> very rapidly. Only 10 algorithms applied successively, each taking 10
> seconds to break, results in a solution time of 10 to the power of 10
> seconds, or about 316 years.
>
> Has any research been done on the existence of "incompatible" algorithms,
> especially in the context of producing arbitrarily secure ciphertext?
I'm not sure I like your term as incompatibility is rather a description
on non-conformity that can be in more directions than what anyone of us
care to imagine.
Your question is more to chainability and its requirements, which also
would imagine a much harder curve of attack than you suggest. And, yes
to the essence of your last question, or the lesson is how to design good
ciphers from selected primatives.
--
Those who think that all useful encryption is done in binary
are destined to be thought of as mere bit-players.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Q: Removal of bias
Date: Wed, 03 Nov 1999 12:12:47 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> Could anyone give references to practical results of removal of
> bias in random number/bit sequences, showing the efficiency of
> the techniques? Thanks in advance.
>
Nature is biased, else we would not be here.
--
Those who think that all useful encryption is done in binary
are destined to be thought of as mere bit-players.
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Q: Removal of bias
Reply-To: [EMAIL PROTECTED]
Date: Wed, 03 Nov 1999 17:58:33 GMT
On Wed, 03 Nov 1999 08:40:52 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>Could anyone give references to practical results of removal of
>bias in random number/bit sequences, showing the efficiency of
>the techniques? Thanks in advance.
>
Well, assuming independence and for simple techniques
like XOR or CRC, it's just straight math;
Assuming a biased bit which is '1' .75 and '0' .25
(entropy = 0.8112781)
Using XOR to combine N bits,
1 bits: Entropy = 0.8112781
2 bits: Entropy = 0.9544340
3 bits: Entropy = 0.9886994
4 bits: Entropy = 0.9971804
(after 12 bits, it's 1.0 to seven places.)
Using the 4 bit CRC 4,3,0 (0xC)
4 bits: Entropy = 3.2451125 (0.8112781 per bit)
8 bits: Entropy = 3.9455857 (0.9863964 per bit)
12 bits: Entropy = 3.9973615 (0.9993404 per bit)
16 bits: Entropy = 3.9999021 (0.9999755 per bit)
(after 28 bits, it's 4.0 to seven places.)
Using the 8 bit CRC 8,5,3,2,0 (0x96)
8 bits: Entropy = 6.4902250 (0.8112781 per bit)
16 bits: Entropy = 7.9725112 (0.9965639 per bit)
24 bits: Entropy = 7.9996154 (0.9999519 per bit)
32 bits: Entropy = 7.9999977 (0.9999997 per bit)
(after 40 bits, it's 8.0 to seven places.)
Is this the sort of thing you were looking for?
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Wed, 03 Nov 1999 11:20:58 -0700
Reply-To: [EMAIL PROTECTED]
Scott Nelson wrote:
> On 3 Nov 1999 08:33:45 -0500, [EMAIL PROTECTED] (Patrick Juola)
> wrote:
>
> >In article <[EMAIL PROTECTED]>,
> >Tony T. Warnock <[EMAIL PROTECTED]> wrote:
> >>Uncle Al wrote:
> >>
> >>> The digits of pi are purely random (except for being pi). We've got
> >>> pi to about 50 billion decimal places. Nobody would suspect using the
> >>> digits of pi becaise it is not a random number. No problem. Use pi.
> >>
> >>I would like some reference to this. As far as I know, no one has proved
> >>that the digits of pi are purely random, quasi random, non random,
> >>uniformly distributed, etc.
> >
> >I believe pi has been proved "normal", which is to say that every
> >finite-length string appears equiprobably in the extended decimal
> >expansion. In point of fact, I think it's been proved "normal to
> >all bases," which means the same holds in the octal, hexadecimal,
> >binary, septal, &c. expansions.
> >
> >Not that this necessarily means much w.r.t "randomness" as
> >0.12345678910111213.... is also "normal," at least to base 10, and
> >I believe to all bases.
> >
> >And, no, I don't have a reference offhand, but it should be addressed
> >in a decent analysis text.
> >
> > -kitten
>
> All the numbers might appear in the decimal expansion of PI,
> but they aren't equiprobable. Long runs of zeros can't occur
> early, so their probability is lower. Other repeating patterns
> are also impossible in early positions. Thus, PI has been
> proved to be "non-normal" although the bias is so slight
> that only a mathematician would make the distinction.
>
> Scott Nelson <[EMAIL PROTECTED]>
NO, what happens at the beginning is irrelevant. No finite changes make any
difference. There's always an infinite tail to make up anything. Look at
Champernowne's number (base 2); commas to indicate construction.
0,1,10,11,100,101,110,111,1000,1001,1010,1011,1100,1101,1110,1111...
After N bits there are about N/Log(N) too many 1 bits. The number is still
normal. Normality is weak but pi still isn't know to be normal.
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: What is the deal with passwords?
Date: Wed, 03 Nov 1999 13:40:12 GMT
On Wed, 03 Nov 1999 03:41:47 GMT, Tom St Denis <[EMAIL PROTECTED]> wrote:
>> Thats different from what you originally said. And its true, PGP does
>> not have to be anything like 7mb to offer the encryption it does.
>
>Bingo. The install is 7.5mb. Even if I only want to encrypt a silly
>message or email or something.
>
>Tom
If you want to do without the extras, use an older version of PGP, 2.6.3i
compiles into an executable of 151k. If you don't want the extras, you aren't
required to use them. And you aren't required to use a password to protect
your PGP key, just hit enter when asked for one.
Best Wishes,
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: crypto and dependencies
Date: Wed, 03 Nov 1999 18:43:32 GMT
[EMAIL PROTECTED] wrote, in part:
>I'm trying to build a model for Internet Security, one component
>of which is cryptography. Upon what (example: time, bandwidth, ...)
>does "cryptography" depend for the purpose of generating capability
>trends?
Processor clock speeds, I suppose, if I must choose one.
More specifically:
the capability of the encryptor increases exponentially with computer
power available at a fixed reasonable cost (encrypting something
doesn't get any faster with parallel computers at all).
the capability of the eavesdropper increases linearly with computer
power, but also increases linearly as computers become cheaper
(cracking a cipher scales perfectly on a parallel computer).
This is still an incredible oversimplification, but it's probably the
closest thing to the kind of answer you're looking for.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: cryptohoping
Date: Wed, 03 Nov 1999 18:51:11 GMT
fungus <[EMAIL PROTECTED]> wrote, in part:
>A brute-force search for
>and n-bit key is still a brute-force search for an n-bit key,
>no matter how weird the algorithm is.
But the algorithm has to be weird enough so that the brute-force
search will actually be required, of course.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Wed, 03 Nov 1999 19:02:51 GMT
In article <[EMAIL PROTECTED]>,
fungus <[EMAIL PROTECTED]> wrote:
>
>
> Simon DeDeo wrote:
> PS: You could try this. It's useless for crypto but it should work
> for your simulation...
>
> /*
> C This random number generator originally appeared in "Toward a
> Universal
> C Random Number Generator" by George Marsaglia and Arif Zaman.
> C Florida State University Report: FSU-SCRI-87-50 (1987)
> C
> C It was later modified by F. James and published in "A Review of
> Pseudo-
> C random Number Generators"
> C
> C THIS IS THE BEST KNOWN RANDOM NUMBER GENERATOR AVAILABLE.
> C (However, a newly discovered technique can yield
> C a period of 10^600. But that is still in the development
> stage.)
> C
> C It passes ALL of the tests for random number generators and has a
> period
> C of 2^144, is completely portable (gives bit identical results on
all
> C machines with at least 24-bit mantissas in the floating point
> C representation).
> C
> C The algorithm is a combination of a Fibonacci sequence (with lags of
> 97
> C and 33, and operation "subtraction plus one, modulo one") and an
> C "arithmetic sequence" (using subtraction).
>
Better yet is the Mersenne Twister[800], with a period of 2^19937-1, and
optimial equidistribution properties in up to 623
dimensions. You can find more information on this at:
http://www.math.keio.ac.jp/~matumoto/emt.html.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: unpacker to trace code
Date: 03 Nov 1999 19:20:23 GMT
Virginie Robbins [EMAIL PROTECTED] writes:
>Anyone knows a good unpacker to trace code ?
Anyone says try here:
http://www.SuddenDischarge.com/
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Wed, 03 Nov 1999 19:31:02 GMT
Uncle Al <[EMAIL PROTECTED]> wrote, in part:
>The digits of pi are purely random (except for being pi). We've got
>pi to about 50 billion decimal places. Nobody would suspect using the
>digits of pi becaise it is not a random number. No problem. Use pi.
No, no, no, no. Pi is publicly known. Even using digits from the local
phone book is no good! Ditto Rand's One Million Digits (avalable on
the web for free from Rand, good guys!).
There are times in cryptography when you _really_ need randomness.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Q: Removal of bias
Date: Wed, 03 Nov 1999 19:18:06 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> > For x = 0 to size
> > Ax = 0
> > For y = nx to nx + n
> > Ax = Ax xor By
> > next y
> > next x
>
> Please re-read my sentences to see whether you were answering
> to that. I was questioning whether there are publically availbable
> results of removing statistical bias from given random number/bit
> sequences and whether the techniques involved prove to ge good
> in practice. What has your program have to do with that at all???
If you lean towards 1 or 0 (but not completely) xoring several bits
together can 'flatten' out the bias. I read this in AC somewhere. I am
not into the probabilities right now but I could dig em up if you want.
I think it works similar to this line of thinking [i Could be wrong I
am a bit tired now]. If you have a p(1) = 0.5 + 0.25 then xoring two
consecutive bits gives you p'(1) = p(1)^2 or p'(1) = 0.5625 which is
only 0.0625 from normal. (p(1)^3 is 0.4218 thus no better). Obviously
this cannot be perfect (unless you can xor fractional bits) but can get
better. you also have to know the bias of the bits before hand.
[ this is also an order-0 algorithm... ]
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: Wed, 03 Nov 1999 19:24:39 GMT
In article <[EMAIL PROTECTED]>,
Anton Stiglic <[EMAIL PROTECTED]> wrote:
> That would be a good idea. Because even I am, say, a single user
that is
> running
> a 486 using windows 95 and just have a simple internet connection,
this
> internet
> connection is an open door. If I can view web pages, if I can
download
> Java Scripts,
> Active-X stuff, Java applets, I am somewhat vulnarable to people
beeing
> able to read
> my file. Beleive me, there will always be a loop hole here, look at
all
> the stuff Active-X
> can do to damage you, look at Java applets that were tought to be in a
> "sand-box",
> guaranteed to not read or write to your files, but seem to have some
loop
> holes where
> in fact they could in fact read and write to your disk. As soon as
you
> have an internet
> connection, you must protect your jewelery.
>
> For low entropy passwords, why don't you use key stretching. It's a
great
> scheme
> described in the article:
> "Secure Applications of Low-Entropy Keys", from Kelsey, Schneier,
Hall and
> Wagner.
>
> For those who don't know about it, you use several iterations of a
> cryptographicaly
> secure hash function on your password, the result is a 160-bit
password if
> you are using
> say SHA-1. They demontrate that there are no shoort cuts to getting
that
> result, you
> have to execute the n iterations to get the result. So if someone is
> trying a dictionnary
> attack, he has to execute the n iterations of the hash function to
see if
> what he gets is
> in fact the key. You choose n in such a way that it takes a 1-2
seconds in
> a fast machine.
> They also proove that the 160-bit result is polynomialy
indistinguishable
> from true 160-bit
> randomness. It realy is a nice result.
I am in the midst of adding it right now (should be ready in a couple
days). Basically encrypting the keyring is optional, but if you do it
will hash your password+time_stamp to get a 160-bit session key fed to
RC4 to encrypt the data. Why RC4? Because I want to make a wrapper
around fwrite which will encrypt data in byte units if a password is
used. (this makes the code easier...).
So stay tuned (check the website out, or here, or the mail list...)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Wed, 03 Nov 1999 19:28:12 GMT
[EMAIL PROTECTED] (Vernon Schryver) wrote, in part:
>If you can detect any and all men in the middle who have broken the
>initially "secure and certified" link, then there less reason to negotiate
>additional ciphers. If you doubt the initial cipher, you won't use it
>to negotiate new ciphers, since you can't trust the results of any
>negotiating covered by the initial cipher.
But the idea is that one could use something on the order of
heptuple-AES as the initial cipher, and now that the algorithms are
*variable*, one could get by with _mere_ triple encryption thereafter.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
** 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
******************************
