Cryptography-Digest Digest #822, Volume #13 Tue, 6 Mar 01 17:13:00 EST
Contents:
Re: Super strong crypto (David Wagner)
Re: super strong crypto, phase 3 (David Wagner)
Re: super strong crypto, phase 3 (David Wagner)
Re: beyond "group signatures": how to prove sibling relationships? (David Wagner)
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Re: => FBI easily cracks encryption ...? ("Mxsmanic")
Re: => FBI easily cracks encryption ...? ("Mxsmanic")
Re: => FBI easily cracks encryption ...? ("Mxsmanic")
Re: PKI and Non-repudiation practicalities (Anne & Lynn Wheeler)
Re: Monty Hall problem (was Re: philosophical question?) (Shawn Willden)
Re: PKI and Non-repudiation practicalities (Anne & Lynn Wheeler)
Re: Again on key expansion. ("Cristiano")
Re: The Foolish Dozen or so in This News Group (Darren New)
Re: PKI and Non-repudiation practicalities (Anne & Lynn Wheeler)
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Re: One-time Pad really unbreakable? ("Mxsmanic")
Re: super strong crypto, phase 3 (John Savard)
Re: super strong crypto, phase 3 (John Savard)
Re: super strong crypto, phase 3 (John Savard)
Re: super strong crypto, phase 3 (John Savard)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Super strong crypto
Date: 6 Mar 2001 20:23:04 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Douglas A. Gwyn wrote:
>There is *no* possible attack against
>the phase 3 straw man in the classes noted, which include those
>that are usually the most promising avenues for cryptanalysis.
That's not true. I'll give you a counterexample.
Suppose for my block cipher I use the following particularly
dumb choice: E_k(x) = k xor x. (If you'd like the keyspace
to be larger than the plaintext space, then you can use
E_k(x) = k1 xor k2 xor ... xor kn xor x.) It is easy to see
that your mode will be insecure when used with this cipher.
This is a completely silly example, but it is sufficient to
show that your claim is wrong. It is a counterexample to the
any claims of the impossibility of attack.
This demonstrates that you have to make *some* assumptions
about the underlying block cipher. Now, you could argue that
only very weak assumptions are required, but I do not think
that anyone who is talking knows exactly what assumptions are
required, or can give any example of a cipher that is known
to satisfy those assumptions.
You said "one could concoct proofs of the specific security
claims" you made. I would like to see them, or at very least
see precise statements of what you believe can be proven.
Does the above counterexample change your mind?
(It is very easy to make informal statements which sound quite
plausible but turn out to be false when you try to work out the
details. That's why I am urging you to be more precise in your
statements of claims. In my view, providing a statement and
proof of the results is not merely "filling in the details" nor
"mere academics"; rather, in a field where intuition often leads
astray, it is one of the few reliable ways we have of holding
ourself to a very high standard of reasoning and ferreting out
fallacies.)
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: super strong crypto, phase 3
Date: 6 Mar 2001 20:25:12 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Douglas A. Gwyn wrote:
>However, with a different key for each
>block it is hard to see how any differential attack could be
>mounted.
Why is it hard to see? I already gave a scenario, which I will
claim is not entirely implausible, wherein a differential attack
could be mounted despite the fact that the key changes every block.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: super strong crypto, phase 3
Date: 6 Mar 2001 20:27:37 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Douglas A. Gwyn wrote:
>That means the only hope for the cryptanalyst is to attack
>multiple blocks simultaneously, but since they use
>different keys (unrelated to each other, if one chooses to
>spend a little more bandwidth than I originally suggested)
>it is hard to see how correlations might be established.
But the different keys *are* related. They are related in that
each key is generated from the previous key by shifting in 64 bits
of fresh material, where the fresh material was encrypted under the
old key. Now, this relationship might be highly nonlinear, and it
might be unclear how to find any way to exploit this relationship
between the keys, but the keys surely are related, no?
Did I miss something?
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: beyond "group signatures": how to prove sibling relationships?
Date: 6 Mar 2001 20:31:20 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Fen Labalme wrote:
>the players (sorry if the notation is non-standard):
>
>T a "parent" public key pair
>
>use of T's secret key may be involved in the generation of its "child" nyms:
>
>Ci a "child" of T (public key pair) named "i"
>Cj a "child" of T (public key pair) named "j"
>Ck a "child" of T (public key pair) named "k"
>
>desired properties:
>
>1) Ci, Cj, Ck cannot prove who its parent (T) is
>
>2) Ci, Cj, Ck cannot prove they are siblings
>
>3) T can prove parenthood of children (e.g. Ci, Cj, and/or Ck)
>
>4) T is able to prove Ci and Cj are siblings
I don't understand; is there something more?
Maybe you mean that Ci,Cj,Ck are supposed to be able to sign
statements so that the signature can be verified using T's public
key, and so that the signature do not reveal which child signed
the message? Did you mean to require something like that?
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Tue, 06 Mar 2001 12:31:47 -0800
Eric Lee Green wrote:
>
> On Tue, 06 Mar 2001 05:20:22 -0800, Anthony Stephen Szopa <[EMAIL PROTECTED]
> > wrote:
> >Are you qualifying this to be restricted to hard drives only?
> >
> >Or do you mean all this applies to floippy disks, too?
>
> On Windows 98 SE, at least, the default for removable drives is that the
> OS does NOT do write-behind caching. This is a control panel setting.
> Floppies are a removable drive.
>
> You can disable write-behind caching for hard drives on Windows 98 SE
> via the control panel, as described in an earlier post. This does not,
> however, address the problem of the buffer inside SCSI disk drives, or
> the problem of NTFS not operating the way you think it should on
> Windows 2000/Windows NT, or Windows 2000/NT in general.
>
> Note that you can detirmine the effects of write-behind buffer caching
> quite well by mounting a MS-DOS floppy disk on a Linux system and writing
> some data to it. Where it'll go "gronk-gronk-gronk" on a Windows box, it
> will go "click-click-click" from first modified sector to last as Linux
> optimizes the disk access (and will write much faster as a result).
> The 'sync' option in the 'mount' command will turn off the write-behind
> buffer caching on Linux and then you get the same 'gronk-gronk-gronk' that
> you get with Windows. An application, however, has no way of knowing
> whether the write-behind buffer caching is turned on or not.
>
> --
> Eric Lee Green [EMAIL PROTECTED] http://www.badtux.org
> AVOID EVIDENCE ELIMINATOR -- for details, see
> http://badtux.org/eric/editorial/scumbags.html
>
> -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
> http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
> -----== Over 80,000 Newsgroups - 16 Different Servers! =-----
You have provided the best on topic reply post here to date by far.
Thanks for agreeing that the OverWrite program works as described
for floppies. At least this is out of the way.
I am of the opinion that it would be best to insure that the hard
drive is written to regardless of if the write behind caching as MS
calls it is disabled or not.
All of this becomes academic if we finally address the issue of
when the write will or must take place instead of when the write
will not necessarily take place.
Some have alluded to this and I have updated the OverWrite program
accordingly.
Do you have any thoughts on this since this is going for the issue's
jugular?
Obviously no one has any thoughts on this or has declined to share
them.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Tue, 06 Mar 2001 12:45:05 -0800
Doom the Mostly Harmless wrote:
>
> > I like my software to be criticized if the criticism has merit.
> >
> > How about this: "Your interface sucks!"
> >
> > Now that's criticism.
>
> Technically, yes. That is criticism. But is it criticism with merit? I
> suppose that depends on who you ask. My guess is that a poll of sci.crypt
> would reveal that people here care a lot less about what you (or your
> software) look like, and more about what you (or it) can do.
>
> If you want your interface criticized, I suggest you submit it to one of the
> GUI programming newsgroups. Here, we worry about how (or whether) things
> actually work.
>
> Two more points. You responded to my last post with a long rant about how
> well your software works on floppy disks. I never denied that your software
> did what it says. Personally, I've not taken a close enough look at any of
> my hardware or the deep internals of my disk drivers to really know. That's
> far from my area of specialty. In any case, I don't keep anything on my
> hard drive I wouldn't want the gov't (or my parents, for that matter) to
> see, so I have no percieved need for your software, and convincing me that
> it works ain't gonna do you any good whatsoever.
>
> --
> To air is human....
> --Doom.
I don't think most everyone has said that the OverWrite program
doesn't do what it is supposed to do.
What most have been saying is that it MIGHT NOT and in some cases
some think it probably doesn't.
I have been quite aware this.
I have updated the software in a way that I think will if not
force the write at least allow the write to actually take place under
most circumstances.
I have figured out a way to test for at least one of the points made
about not overwriting to the original file and writing to a completely
different file but it will take some time since I have many other
things to do.
The criticism I mention about the GUI was said in these news groups
and there have been many more criticisms just like this one.
I think Hollyfield and Cooney before him might have taken low blow
lessons from some of them.
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Tue, 06 Mar 2001 20:53:56 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I just hope he never was in a position to affect
> how nuclear codes are loaded in missles.
It's hard to see how loading codes in missiles has anything at all to do
with the FBI.
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Tue, 06 Mar 2001 20:54:58 GMT
"kroesjnov" <[EMAIL PROTECTED]> wrote in message
news:983gdv$2v9lq$[EMAIL PROTECTED]...
> Something alike, check it out:
> http://www.thestandard.com/article/display/0,1151,22589,00.html
> May not have as much as an impact as getting the
> nuclear codes, but yet, it does have a large impact...
Not at all. Read the article carefully. The hacker found source code
for an operating system. Big deal. There is no danger in this at all
that I can see.
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Tue, 06 Mar 2001 20:56:18 GMT
"kroesjnov" <[EMAIL PROTECTED]> wrote in message
news:983ftk$2v5dt$[EMAIL PROTECTED]...
> But the protection off the police force, or
> any other agency, that they give me from terrorists,
> makes me feel saver, which in turn makes me happier.
You seem to see terrorists under every rock. When was the last time
they attacked your home?
------------------------------
Subject: Re: PKI and Non-repudiation practicalities
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Tue, 06 Mar 2001 20:57:28 GMT
"Lyalc" <[EMAIL PROTECTED]> writes:
> I've always taken the view that non-repudiation, at a commercial level, is
> implementation dependent, regardless of the underlying technology.
> Certificates/PKI use a shared 'secret' such as a password or biometric
> The 'weakest link' rule means that shared secrets/passwords are the thing to
> focus on for really getting PKI secure, even after the expertise devoted to
> PKI comes up with the answer to the PKI part of the puzzle.
pins/passwords/biometrics for activating a hardware token is significantly
different from pins/passwords/biometrics used as shared-secrets.
it is possible to do 3-factor authentication with no shared-secret
1) something you have
2) something you know
3) something you are
using hardware token that requires both pin & biometric .... where the
business process of a pin activated card is significantly different
from a business process shared-secret PIN (even if they are both PINS).
hardware token with a pin & biometric requirement can be used to meet
3-factor authentication ... and a shared secret secret doesn't exist.
and doing it w/o impacting the business process infrastructure
.... separate issue from impacting the technology implementation;
pilots tend to be technology issues ... real deployment frequently are
business process issues.
similar discussion in sci.crypt from last oct:
http://www.garlic.com/~lynn/2000e.html#40
http://www.garlic.com/~lynn/2000e.html#41
http://www.garlic.com/~lynn/2000e.html#43
http://www.garlic.com/~lynn/2000e.html#44
http://www.garlic.com/~lynn/2000e.html#47
http://www.garlic.com/~lynn/2000e.html#50
http://www.garlic.com/~lynn/2000e.html#51
http://www.garlic.com/~lynn/2000f.html#0
http://www.garlic.com/~lynn/2000f.html#1
http://www.garlic.com/~lynn/2000f.html#14
http://www.garlic.com/~lynn/2000f.html#15
http://www.garlic.com/~lynn/2000f.html#2
http://www.garlic.com/~lynn/2000f.html#22
http://www.garlic.com/~lynn/2000f.html#23
http://www.garlic.com/~lynn/2000f.html#24
http://www.garlic.com/~lynn/2000f.html#25
http://www.garlic.com/~lynn/2000f.html#3
http://www.garlic.com/~lynn/2000f.html#4
http://www.garlic.com/~lynn/2000f.html#7
http://www.garlic.com/~lynn/2000f.html#8
--
Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
------------------------------
From: Shawn Willden <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers,de.sci.informatik.misc,sci.math
Subject: Re: Monty Hall problem (was Re: philosophical question?)
Date: Tue, 06 Mar 2001 13:23:16 -0700
Benjamin Goldberg wrote:
> Shawn Willden wrote:
> [snip]
> > int carPos = r.nextInt(3);
> > int choice = r.nextInt(3);
>
> I'm not going to comment on anything else, but nextInt(3) returns 3
> random bits, or a number in the range 0..7. To get an unbiased int in
> the range 0..2, you have to write your own ranmod type function.
In case you're interested (and to bring this discussion a little closer to
the charter of sci.crypt, where I'm reading it), the implementation of
java.util.Random.nextInt(int n) is:
public int nextInt(int n) {
if (n<=0)
throw new IllegalArgumentException("n must be positive");
int bits, val;
do {
bits = next(31);
val = bits % n;
} while(bits - val + (n-1) < 0);
return val;
}
Any comments on the quality of this ranmod function?
Shawn.
------------------------------
Subject: Re: PKI and Non-repudiation practicalities
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Tue, 06 Mar 2001 21:00:50 GMT
"Lyalc" <[EMAIL PROTECTED]> writes:
> Yep, there is a massive phase out challenge for the migration away from
> single DES to 3DES or AES.
or public key ... the cut-over costs are effectively the same for
single solution or multi-solution cut-over deployment. hardware token
card with digital signatures can actually reduce various
infrastructure costs associated with shared-secret activites (again a
hardware token requiring a PIN is done w/o having the PIN a
shared-secret).
--
Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
------------------------------
From: "Cristiano" <[EMAIL PROTECTED]>
Subject: Re: Again on key expansion.
Date: Tue, 6 Mar 2001 22:11:25 +0100
> > > [...]
> > > Two methods that both take a second offer the same strength.
> >
> > This point is not clear (for me). I'd like better understand what you
> > tell me:
> > to add 13 bits of entropy to my key my method takes 0.079 s, SALEK's
> > method takes 1.26 s (on *my* computer with *my* program).
> > Why the two methods offer the same strength?
> > In the same time my method add more entropy to the key.
> > I don't want to blame SALEK's method, I want only understand and
> > learn!
>
> The disparity is due to your miscounting the number of rounds.
> To multiply a point by a 512 bit integer is 512 doublings, and 256 adds.
> To perform sha512 once, is 64 internal rounds.
>
> (Note, I forgot the adds in my earlier estimate).
Miracl library use the addition/subtraction method: to multiply a point by a
512 bit integer is 511 (or 512) doublings, and 40 adds (I think the
subtraction is not important for the entropy).
> Your method, looping 16 times adds log2(16*(512+256+64)) bits of work.
> SALEK's method, looping 2^13 times adds log2(2^13*64) bits of work.
>
> So your method takes .079s to add 13.7 bits of work.
> SALEK's method takes 1.26s to add 19 bits of work.
I forgot to specify in my message that I have used sha256.
With sha512 my method takes .378 s to add log2(16*(512+40+64)) = 13.3 bits
of work (but "work" is "entropy"?), SALEK's method takes .026 s to add
log2(2^7*64) = 13 bits of work.
With sha512, my method needs 2^e/616 iterations to add e bits of work,
SALEK's method needs log2(2^(e-6)) iterations to add e bits of work (and
SALEK's method is very fast!).
I have only a doubt: I don't think that a single round of sha is the same as
a single doubling of a point in GF(p). In other words, a doubling of a point
in GF(p) should be compared with the whole sha, not with a single round of
sha. What do you think?
> Thus, by attempting to measure rounds more accuratly, we end up with a
> more accurate measurement of how much the two methods should differ.
Thank you very much for your clear explanation!
Cristiano
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Tue, 06 Mar 2001 21:27:17 GMT
Anthony Stephen Szopa wrote:
> Thanks for agreeing that the OverWrite program works as described
> for floppies. At least this is out of the way.
Have you tried running it with SmartDrv turned on, write-behind caching
there, and a big enough buffer to hold an entire floppy?
> Obviously no one has any thoughts on this or has declined to share
> them.
Erm....
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
------------------------------
Subject: Re: PKI and Non-repudiation practicalities
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Tue, 06 Mar 2001 21:32:21 GMT
Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes:
> or public key ... the cut-over costs are effectively the same for
> single solution or multi-solution cut-over deployment. hardware token
> card with digital signatures can actually reduce various
> infrastructure costs associated with shared-secret activites (again a
> hardware token requiring a PIN is done w/o having the PIN a
> shared-secret).
from various AADS & X9.59 writings at
http://www.garlic.com/~lynn/
take the fully loaded existing costs of sending out a new magstripe
card. the incremental costs of injecting a chip into that card is
somewhere between 10% and 50% of the fully loaded costs of turning out
a new card.
given the chip has the characteristics of a hardware token and doesn't
implement shared secrets ... then the financial requirement for
needing a unique magstripes with unique shared secrets is alleviated
(i.e. shared secrets are not being divulged to different financial and
commercial organizations).
with x9.59 for all electronic retail transactions ... then
theoritically, a single hardware token performing digitally signed,
x9.59 authenticated transactions ... would not have a financial
security issue if the token were used for multiple different accounts,
potentially leading to a reduction in the number of cards shipped
(because the infrastructure has switched away from shared-secret
... even if the token is PIN activated).
furthermore, in the current credit card world, "expiration date" is
used as sort of an authentication code (i.e. you can randomly guess a
credit card number with some realistic chance of it being valid
.... also guessing the corresponding expiration date is much lower
probability). a hardware token supporting authenticated (x9.59)
transactions minimizes the requirement that an expiration date needs
to be carried on the card as a kind of authentication code.
Given that the incremental cost of injecting a chip into an existing
card delivery business process is at <100% than the current fully
loaded costs, then if the chip can be used to eliminate at least one
other card delivery ... there is a net savings to the infrastructure.
If the
1) ATM swap-out costs have no negligable difference in the cost of
the kind of technology and/or number of technologies supported
2) and if the backend costs can be significantly reduced by moving to a non-shared
secret infrastructure
3) and if the elimination of shared-secrets and/or other chip related
characteristics reduces the number of cards that have to go out
then there is net reduction in business costs .... independent of
issues related to fraud reduction with the migration to better
authenticated transactions ... and independent of any non-repudiation
cost reduction issues.
i.e., by appropriately applying technology to basic business processes
there is opportunities for cost reduction.
This approach is completely different from one that might look at the
total costs of deploying hardware tokens and authentication technology
as part of a brand new infrastructure, totally unrelated to any
existing business purpose (not how much more it costs, but how much
less it costs).
--
Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Tue, 06 Mar 2001 13:34:56 -0800
Doom the Mostly Harmless wrote:
>
> > I like my software to be criticized if the criticism has merit.
> >
> > How about this: "Your interface sucks!"
> >
> > Now that's criticism.
>
> Technically, yes. That is criticism. But is it criticism with merit? I
> suppose that depends on who you ask. My guess is that a poll of sci.crypt
> would reveal that people here care a lot less about what you (or your
> software) look like, and more about what you (or it) can do.
>
> If you want your interface criticized, I suggest you submit it to one of the
> GUI programming newsgroups. Here, we worry about how (or whether) things
> actually work.
>
> Two more points. You responded to my last post with a long rant about how
> well your software works on floppy disks. I never denied that your software
> did what it says. Personally, I've not taken a close enough look at any of
> my hardware or the deep internals of my disk drivers to really know. That's
> far from my area of specialty. In any case, I don't keep anything on my
> hard drive I wouldn't want the gov't (or my parents, for that matter) to
> see, so I have no percieved need for your software, and convincing me that
> it works ain't gonna do you any good whatsoever.
>
> --
> To air is human....
> --Doom.
You make a good Subject.
Off topic so I will not post any more of my reply.
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Date: Tue, 06 Mar 2001 21:38:12 GMT
"Sundial Services" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> ... (c) a bulletproof way of recovering from the inevitable
> transmission-errors.
Not necessary. Errors are not propagated or amplified by OTPs, so an
error of n bits in the key or ciphertext produces only an error of n
bits in the plaintext upon decryption. Additionally, since OTPs offer
perfect security, any degree of redundancy or error correction can be
included in the plaintext in order to provide any arbitrary level of
message integrity (short of perfection).
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: super strong crypto, phase 3
Date: Tue, 06 Mar 2001 21:05:12 GMT
On Tue, 06 Mar 2001 11:26:56 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>Thanks. The other question of mine was whether it might not
>be better to vary keys but without transmitting any new key
>informations online.
Well, that question is sort of irrelevant. One transmits new keys
offline as often as one can; the question here is whether in the
interim, transmitting new key information online is useful.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: super strong crypto, phase 3
Date: Tue, 06 Mar 2001 21:07:45 GMT
On Mon, 05 Mar 2001 04:22:10 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>And in this form, I've added a diagram of this to my web page at
>http://home.ecn.ab.ca/~jsavard/crypto/mi060901.htm
And I've now linked this page to another page on my site also
discussing something similar (the second half of the "Large-Key
Brainstorm" page).
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: super strong crypto, phase 3
Date: Tue, 06 Mar 2001 21:06:41 GMT
On 6 Mar 2001 20:27:37 GMT, [EMAIL PROTECTED] (David Wagner)
wrote, in part:
>Did I miss something?
Well, he did say 'spend a bit more bandwidth', so now a fresh new
complete 128-bit key is used each time.
But it's still transmitted under the old key, so *that* relationship
still exists.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: super strong crypto, phase 3
Date: Tue, 06 Mar 2001 21:15:10 GMT
On Mon, 05 Mar 2001 06:54:19 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote, in part:
>The general principle is to avoid detailed analysis
>of specific special attacks, and concentrate instead
>on protection against important general methods of
>attack. If all of these can be defeated then the
>result would merit the appellation "super strong".
Perhaps you might be interested in the concepts I've toyed with at:
http://home.ecn.ab.ca/~jsavard/crypto/co041205.htm
which I've now linked to the other page where I discuss your idea.
John Savard
http://home.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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
