Cryptography-Digest Digest #823, Volume #13 Tue, 6 Mar 01 21:13:01 EST
Contents:
Re: super strong crypto, phase 3 (Mok-Kong Shen)
Re: NTRU - any opinions (DJohn37050)
Re: Test vectors for 3DES with OFB or CFB (DJohn37050)
Re: super strong crypto, phase 3 (Steve Portly)
Re: NTRU - any opinions ("Michael Scott")
Re: One-time Pad really unbreakable? ("Douglas A. Gwyn")
Re: => FBI easily cracks encryption ...? (Matthew Montchalin)
Re: super strong crypto, phase 3 (John Savard)
Re: => FBI easily cracks encryption ...? (Free-man)
Re: Super strong crypto ("Douglas A. Gwyn")
Re: super strong crypto, phase 3 ("Douglas A. Gwyn")
Re: super strong crypto, phase 3 ("Douglas A. Gwyn")
Re: ___indeed 2x2 Matrix RSA (Tony L. Svanstrom)
Re: super strong crypto, phase 3 ("Douglas A. Gwyn")
Re: super strong crypto, phase 3 ("Douglas A. Gwyn")
Re: super strong crypto, phase 3 ("Douglas A. Gwyn")
Re: => FBI easily cracks encryption ...? (Jerry)
Re: super strong crypto, phase 3 (David Wagner)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: super strong crypto, phase 3
Date: Tue, 06 Mar 2001 23:20:40 +0100
John Savard wrote:
>
> 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.
Sorry, I expressed myself wrongly. I meant that in one case
one never sends in the bit sequences anything that has to
do with the (new) keys, for these are generated according
to some scheme at the timepoints of need by both communication
partners, while in the proposal of Douglas Gwyn these keys
are chosen by the sender and transmitted to the receiver in
encrypted form. (I should have said 'over the line' instead
of 'online'.) I guess that it may be better to arrage to have
the new keys be generated rather than sending them encrypted.
Anyway, a comparison seems worthy of being studied.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 06 Mar 2001 22:38:43 GMT
Subject: Re: NTRU - any opinions
It is very new.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 06 Mar 2001 22:40:06 GMT
Subject: Re: Test vectors for 3DES with OFB or CFB
NIST has a validation system to TDES.
Don Johnson
------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Subject: Re: super strong crypto, phase 3
Date: Tue, 06 Mar 2001 18:41:29 -0500
John Savard wrote:
> 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
By increasing bandwidth we are forcing an attacker to look deeper down
the key chain for feedback. In order to make this algorithm provably
secure we would need to have a value such as the maximum size of Hilbert
space that could be achieved by the attacker.
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: NTRU - any opinions
Date: Tue, 6 Mar 2001 17:36:36 -0600
""James Russell"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Does anyone here have any opinions on the viability of NTRU's public key
> algorithm?
>
It looks very interesting. See
http://grouper.ieee.org/groups/1363/new/P1363.1-NSSSubmission.pdf
One thing that annoys me is the impossibility of independently checking the
performance "comparisons". Comparisons are made to RSA and ECDSA on a
Pentium, without any mention of clock speed or other details one would need
to check the claims.
In the Table 1 it is suggested that ECDSA signature takes longer than ECDSA
verification, which just doesn't make sense.
Mike Scott
> Thanks.
>
> James
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
>
>
> --
> Posted from [206.156.202.110] by way of f220.law10.hotmail.com
[64.4.15.220]
> via Mailgate.ORG Server - http://www.Mailgate.ORG
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Date: Tue, 06 Mar 2001 23:45:47 GMT
Sundial Services wrote:
> In the real world, you and I will never meet on a park-bench
> somewhere and exchange coded passphrases and two rolled-up
> newspapers.
However, some people (e.g. spies) really do this sort of thing, to
ensure that their future communication cannot be read by others.
> Yet we can send e-mail traffic between ourselves, using off-the-
> shelf crypto, and be reasonably assured that this traffic will
> not be recovered by a third party -- ...
You are perhaps *given* assurances, but why do you believe them?
The nearby "super strong crypto" threads have been exploring
possible ways to gain believable assurance.
------------------------------
From: Matthew Montchalin <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Tue, 6 Mar 2001 15:50:05 -0800
On Tue, 6 Mar 2001, Mxsmanic wrote:
|"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.
The FBI and the CIA share their computer files with each other. Since
personnel records can be accessed by computer, many 'shining stars'
can be targeted for compromise.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: super strong crypto, phase 3
Date: Tue, 06 Mar 2001 23:52:38 GMT
On Tue, 06 Mar 2001 18:41:29 -0500, Steve Portly
<[EMAIL PROTECTED]> wrote, in part:
>In order to make this algorithm provably
>secure we would need to have a value such as the maximum size of Hilbert
>space that could be achieved by the attacker.
Hilbert space: a space with an infinite number of dimensions, but
including only points at a finite distance from the origin, where
distance is the square root of the integral of the square of the
coordinate distance over the line of dimensions...
it is used in variational methods, but I hesitate to just drop it into
a discussion of cryptography.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Free-man)
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Wed, 07 Mar 2001 00:35:00 GMT
On Tue, 6 Mar 2001 12:48:41 -0600, "Daniel Johnson"
<[EMAIL PROTECTED]> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Beretta wrote in message
><[EMAIL PROTECTED]>...
>>On Sun, 4 Mar 2001 13:10:01 +0100, "kroesjnov" <[EMAIL PROTECTED]>
>>wrote:
>>
>><snip>
>>>
>>>I am willing to trade some privacy for safety.
>><snip>
>>
>>So basically, you are saying that you'll trade your privacy to be a
>>sheep? I.e. you'll give up your rights so that the goverment can play
>>the role of sheepherder?
>
>"They that give up essential liberty to obtain a little
>temporary safety deserve neither liberty nor safety."
> -- Benjamin Franklin, Historical Review of Pennsylvania, 1759
"...and will lose both."
Rich Eramian aka freeman at shore dot net
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Wed, 07 Mar 2001 00:38:50 GMT
David Wagner wrote:
> Suppose for my block cipher I use the following particularly
> dumb choice: E_k(x) = k xor x. ...
I don't understand that, since size(k) < size(x). I suppose
you mean that only size(k) bits of x are mixed with k,
contrary to the stipulation that the block encryption have
reasonable mixing properties.
> It is easy to see
> that your mode will be insecure when used with this cipher.
As would any other mode under those circumstances. That
is a *degenerate* mapping (in the algebraic sense). Any
block encryption function partitions the total masked PT
space into orthogonal components, a completely protected
one (2^128) and the quotient space (2^384). Your choice of
system structure in effect aligns the subspaces with the
masking operation, which makes (part of) it immediately
accessible *with no work required by the analyst*. It is,
as I said before, *important* to consider the work required
by the analyst, which I have done in requiring reasonable
mixing. I.e. there ,ust be too much work required to extract
the mask from the CT. (I suppose you could pick a slightly
less silly, but still mickey-mouse, block function, but in
an actual implementation one would of course make sure that
general inversion of the function is an expensive task.)
> 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.
Under a different set of assumptions than I actually stated.
> 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.
There is more discussion about this above.
> 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?
No, because out of the 2^128 possible masked PTs (and attached
fresh key bits), there is no way (from the data in a single
block) to identify any one of them as more likely than any
other. Due to work factor, only a relatively tiny subset can
be tested further (which is how one picks the key size).
> (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.)
The actual conduct of science rarely involves working out such
details while new territory is being explored; systematization
and filling in gaps usually occurs later. That's due to several
factors, among them being that intuition does not work in a
deductive but rather an inductive mode, preconceptions can
prevent one's even considering "contradictory" or out-of-model
ideas that lead to changes of paradigm, that's what research
assistants are for :-), etc., etc. I have already stated that
there *are* deductive gaps; in filling them in one might turn up
fresh insight into necessary conditions such as using a
nontrivial block function (although I already recognized the
necessity of that).
Don't lose sight of the motivation in a rush to throw out the
baby with the bath water, namely that there is far too low key
entropy in standard (public) symmetric encryption schemes,
virtually guaranteeing cryptanalytic success once the right
technique has been figured out. A solution to that issue lies
behind efforts like Rabin's recent work (involving immense pools
of mutually-accessible key bits) and D.Scott's very-long-key
systems. My attempt involves distributing fresh key entropy at
a great enough rate to wreck statistical methods of cryptanalysis,
with additional measures to prevent *feasible* inversion and to
wreck attempts at depth reading and exploitation of the delta
stream (which would have to be done with the block as the basic
unit). That covers most cryptanalytic methods normally employed
in this scenario. I still would like to see some exploration of
the possibility of an analogue to the delta stream that relates
PT bits in one unit to key bits in the next; intuitively this
would have a high work factor for any block function worth
serious consideration in the first place, but there is a gap
that I *do* feel needs more formal work.
If you have a totally different approach that addresses the same
issues, I am (honestly!) eager to hear about it. My ultimate
goal is for anyone who wants it to be able to actually secure his
communications against eavesdropping by *any* unwanted agent,
not just *hope* that he has done so (which is the current state
of the art). That goal cannot be attained without fresh ideas.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: super strong crypto, phase 3
Date: Wed, 07 Mar 2001 00:47:47 GMT
David Wagner wrote:
> ... but the keys surely are related, no?
The specific example I gave earlier shipped only a half batch of
new key, but I also suggested that if one is uneasy about that,
an entire new key could be shipped. For the parameters I used
that loses another 12.5% of the bandwidth. It was *because* it
was unclear how to exploit the relationship in the "shift in
new half batch" keying model that I felt it was reasonable to
use that trick to significantly reduce overhead, but that is a
separable issue from the rest of the design, and I don't insist
on that form of key update.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: super strong crypto, phase 3
Date: Wed, 07 Mar 2001 00:53:01 GMT
John Savard wrote:
> But it's still transmitted under the old key, so *that* relationship
> still exists.
Ah, but that doesn't seem to be an exploitable relationship,
since the rate of introduction of new unknowns (key) equals
the rate of accumulation of information about them. It is
obvious (and has been pointed out) that once you crack a block
the whole scheme unravels, but that is true of nearly any mode.
What one wants to do is make any other attack no easier than
cracking a block, and make cracking a block have too low a
likelihood-to-work ratio.
------------------------------
Subject: Re: ___indeed 2x2 Matrix RSA
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Date: Wed, 07 Mar 2001 00:53:39 GMT
Mehdi Sotoodeh <[EMAIL PROTECTED]> wrote:
> ------=_NextPart_001_003E_01C0A637.36E0FB20
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> Attached
Where did you learn how to behave in newsgroups...?
> MS word document
Eeeeew...
/Tony
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: super strong crypto, phase 3
Date: Wed, 07 Mar 2001 01:00:30 GMT
Mok-Kong Shen wrote:
> Sorry, I expressed myself wrongly. I meant that in one case
> one never sends in the bit sequences anything that has to
> do with the (new) keys, for these are generated according
> to some scheme at the timepoints of need by both communication
> partners, while in the proposal of Douglas Gwyn these keys
> are chosen by the sender and transmitted to the receiver in
> encrypted form. (I should have said 'over the line' instead
> of 'online'.) I guess that it may be better to arrage to have
> the new keys be generated rather than sending them encrypted.
> Anyway, a comparison seems worthy of being studied.
The trouble with generating new keys is that (except possibly
for quantum methods) randomness cannot be used, only some
algorithm. One then lumps the key generation in with the
"general system" and whatever mutually agreed parameters for
the key generator become the true key for the overall system.
Note that Rabin's recent method was an attempt to extract
true randomness according to some algorithm, and his opinion
was that security would require an immense amount of random
data (accessible to both communicants) sampled over a long
enough time that the adversary could not capture all of it.
My straw-man approach from phase 1 has instead tried to find
a secure way to ship random key bits from one communicant to
the other; the OTP paradox is avoided by stretching use of
each key bit as far as it is safe to do so, which in general
isn't very far (depends on the PT source and system structure).
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: super strong crypto, phase 3
Date: Wed, 07 Mar 2001 01:02:39 GMT
John Savard wrote:
> Perhaps you might be interested in the concepts I've toyed with at:
> http://home.ecn.ab.ca/~jsavard/crypto/co041205.htm
Thanks. I'm glad that somebody has taken a serious interest in
exploring this general direction.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: super strong crypto, phase 3
Date: Wed, 07 Mar 2001 01:13:34 GMT
Steve Portly wrote:
> By increasing bandwidth we are forcing an attacker to look deeper
> down the key chain for feedback. In order to make this algorithm
> provably secure we would need to have a value such as the maximum
> size of Hilbert space that could be achieved by the attacker.
While I'm not sure that it's necessarily a Hilbert space, that is
more or less the right idea. The tricky part in any proof of this
kind is to determine a lower bound on just how much space *has* to
be searched for *any* sure-fire solution. That sure seems like a
hard problem. Harder still if you set a success threshold so that
it becomes a matter of probabilities.
------------------------------
From: Jerry <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Wed, 07 Mar 2001 00:42:15 GMT
On Mon, 05 Mar 2001 20:06:21 GMT, "Mxsmanic" <[EMAIL PROTECTED]> wrote:
> "Joe H. Acker" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>
> > Breaking strong crypto is the most expensive
> > path of several dozens of paths that lead to
> > your private information. Both government
> > agencies and crooks are more likely to break
> > into your appartment ...
>
> An excellent point, often overlooked. Aside from breaking in in an
> obvious way, experts could defeat even the fanciest lock and sneak in
> undetected _far_ more easily than anyone could crack any decent
> encryption scheme.
>
> And even that isn't necessary. The spooks can just park a van across
> the street from your house and watch what you type on your screen. That
> would be a million times cheaper than trying to break your encryption
> the hard way.
>
TEMPEST "eavesdropping" is very resource intensive and not something that's done at
random. If that van's
parked across the street, you did something to bring it
there.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: super strong crypto, phase 3
Date: 7 Mar 2001 02:09:16 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Douglas A. Gwyn wrote:
>John Savard wrote:
>> But it's still transmitted under the old key, so *that* relationship
>> still exists.
>
>Ah, but that doesn't seem to be an exploitable relationship,
How do you know?
>since the rate of introduction of new unknowns (key) equals
>the rate of accumulation of information about them.
Why should this imply that there is no exploitable relationship?
------------------------------
** 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
******************************
