Cryptography-Digest Digest #906, Volume #11 Wed, 31 May 00 23:13:00 EDT
Contents:
Re: RIP Bill 3rd Reading in Parliament TODAY 8th May (Andru Luvisi)
Re: Plain simple (?) question ("Joseph Ashwood")
Re: any public-key algorithm (Mark Wooding)
Re: Description of algorithm for hamilton cycle problem (root)
Re: Use of wasted symmetric key bandwidth in key agreement protocols ("Lyalc")
Re: XTR (was: any public-key algorithm) (Roger Schlafly)
Re: RIP Bill 3rd Reading in Parliament TODAY 8th May ("Scotty")
Re: any public-key algorithm (Roger Schlafly)
Re: No-Key Encryption (David Hopwood)
Re: Compare 3DES's. (David Hopwood)
Re: Is OTP unbreakable? (Joaquim Southby)
Re: Is OTP unbreakable? (Joaquim Southby)
----------------------------------------------------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.politics.uk,uk.telecom
Subject: Re: RIP Bill 3rd Reading in Parliament TODAY 8th May
Date: 31 May 2000 16:17:14 -0700
[EMAIL PROTECTED] (David Boothroyd) writes:
> In article <[EMAIL PROTECTED]>, Andru Luvisi
> <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] (David Boothroyd) writes:
> > [snip]
> > > > Yet there is still a vast weight of legal opinion (more highly respected
> > > > than the government's own law officers),
> > >
> > > Is this possible?
> > >
> > > Are these mysterious givers of legal opinion in some way connected with
> > > organisations who have always been against the Bill?
> > [snip]
> >
> > Even if they are, that does not imply that their legal opinion was
> > influenced by their opposition to the bill.
>
> And likewise the opinions of Government law officers were not influenced
> by their support for the Bill, QED.
My original message:
: Even if they are, that does not imply that their legal opinion was
: influenced by their opposition to the bill. Their opposition may have
: its roots in their legal opinion.
Why did you snip my second sentance?
This was written with the purpose of pointing out a flaw in what I
thought you were attempting to imply, by providing a possible
alternate cause should your highly unconfirmed speculation prove to be
true. I was exposing a flaw in your reasoning, not creating an
opposing argument. If you wish to apply my observation to the
other side, you would be better off saying:
-- And likewise the opinions of Government law officers may not be
-- influenced by their support for the Bill.
Andru
--
==========================================================================
| Andru Luvisi | http://libweb.sonoma.edu/ |
| Programmer/Analyst | Library Resources Online |
| Ruben Salazar Library |-----------------------------------------|
| Sonoma State University | http://www.belleprovence.com/ |
| [EMAIL PROTECTED] | Textile imports from Provence, France |
==========================================================================
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Plain simple (?) question
Date: Wed, 31 May 2000 16:20:18 -0700
It's not necessarily a dead end, it has simply been determined that we do
not believe that DS's methods are as good as many others. The only analysis
of his work has been his own (very few other people have waded through his
entirely convoluted source code that he refuses to document), and he has
made outrageous claims that have not been verified. However he is not as
foolish as tomstd makes him out to be, he does on occassion have brief
glimpses of usefulness, and from what I've seen his compression seems to be
something along those lines. But what he stated was not what you asked, it
should be simple enough to write a number mapping algorithm to whatever you
wish to do, as was said by Jerry Coffin.
Joe
"Alain CULOS" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Ok, lads, I sorta guessed that'd be a dead end. I'm pretty sure this data
is
> just a hoax anyway (not intended to be actually informative for an
investigative
> reader).
>
> tomstd wrote:
> <snip>
>
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: any public-key algorithm
Date: 31 May 2000 23:48:48 GMT
David A. Wagner <[EMAIL PROTECTED]> wrote:
> In article <8h3uiu$ofd$[EMAIL PROTECTED]>,
> Eric Verheul <[EMAIL PROTECTED]> wrote:
> > So your employer is not into either E-commerce (a typical SSL server
> > can not initiate more than a dozen or SSL at the same time) [...]
>
> What makes you think that key generation is the dominant cost of SSL?
> That wasn't my impression...
Indeed it isn't. The main performance problem, I believe, is the actual
key exchange. However, dedicated hardware devices are widely available
for doing RSA (and Diffie-Hellman) key exchange algorithms quickly. I'm
not aware of much support for XTR in any crypto accelerator boxes.
Key generation for standard discrete-log-based systems is extremely
quick anyway, assuming that you have a group and generator already
available -- not unreasonable, I think -- you just think up a random
private key of the right size and do a single modexp to get the public
key. That doesn't strike me as being computationally expensive.
-- [mdw]
------------------------------
From: root <[EMAIL PROTECTED]>
Subject: Re: Description of algorithm for hamilton cycle problem
Date: 31 May 2000 23:28:15 GMT
David Blackman <[EMAIL PROTECTED]> wrote:
DB# root wrote:
>>
>> By the way, I don't think this says anything about P=NP because
>> the Simplex algorithm is not polynomial (or at least that is what
>> I have read).
DB# Simplex can turn exponential for some cases, but usually doesn't in
DB# practice. However there are alternative linear programming algorithms
DB# that are guaranteed to run in polynomial time.
DB# The dubious bit is if you can always turn the Hamiltonian path problem
DB# into a linear program. Those multiple cycles are probably where it will
DB# fail. (I had similar problems trying to do the traveling salesman using
DB# linear programming, and i think someone published a paper proving it
DB# can't be done back in the 1980s.)
I don't understand how you can fail to set it up. You always know
the nodes and edges and their relationship. I admit that I am using
a custom built form of the Simplex algorithm, so it might be that
the failure is in the regular form. But even there, you should
always be able to set it up. I agree that that the multiple cycles
make it difficult to solve. But I have yet to generate a random
graph where I could not find a solution, if it indicated there was a
possible solution. It requires variations of the original problem
to find them, but as everyone has pointed out, it is easy to confirm
that they have been found :-). The main result is that you always can
know whether there is a cycle or not. That never fails. If you can't
generate a basis, there is no cycle.
stan
space is convex, so there can never be a failure to
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Use of wasted symmetric key bandwidth in key agreement protocols
Date: Thu, 1 Jun 2000 10:40:43 +1000
Most of the bandwidth waste is in shipping certificates to and fro,
especially when they average 5k+ from the commercial cert providers.
ECC certs don't help much overall, either.
Lyal
Mark Currie wrote in message <39322a5c$0$[EMAIL PROTECTED]>...
>Hi,
>
>In a communications security application involving an on-line key agreement
>protocol, there often exists additional keying bandwidth which is not
generaly
>used. As an example, if the key exchange protocol involved the use of
>Diffie-Hellman, the typical length of the resultant mutual secret value
could
>be in the order of 128 bytes. Only 16 - 32 bytes are typically required for
use
>as a secret key for data encryption. These bytes can either be directly
>extracted from or be the result of hashing the 128 bytes. I have often
wondered
>how the wasted bytes could be put to good use. One idea is to use them to
>modify the symmetric algorithm used to encrypt the data in some way.
However,
>if not applied correctly, it can in fact weaken the algorithm even if these
>values are secret. Another idea could be to use it in the key expansion
part of
>an algorithm to effectively increase key entropy while not impacting on
>performance.
>
>I would be interested in any other idea's for the use of these often wasted
>bytes to increase data security without (ideally) impacting on the data
>encryption performance.
>
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: XTR (was: any public-key algorithm)
Date: Wed, 31 May 2000 17:47:11 -0700
Ian Goldberg wrote:
> >We didn't state that is was immune to DPA's, only that we found that
> >XTR's natural exponentiation routine made it *less* susceptible than
> >usual exponentiation routines to environmental attacks such as timing
> >attacks and Differential Power Analysis. But please prove us wrong
> >there!
>
> I just don't see any reason why XTR is less susceptible to environmental
> attacks than the above modexp code.
I agree with you. XTR is not any less susceptible to those
attacks. In the case of your code, the attacks will depend
on mod p arithmetic times or power usages depending on the
data, or on whether the conditional branch can be detected.
But the XTR algorithm in the paper has the same problems.
------------------------------
From: "Scotty" <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.politics.uk,uk.telecom
Subject: Re: RIP Bill 3rd Reading in Parliament TODAY 8th May
Date: Thu, 1 Jun 2000 01:30:04 +0100
David Boothroyd wrote in message ...
>In article <[EMAIL PROTECTED]>, Andru Luvisi
><[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] (David Boothroyd) writes:
>> [snip]
>> > > Yet there is still a vast weight of legal opinion (more highly
respected
>> > > than the government's own law officers),
>> >
>> > Is this possible?
>> >
>> > Are these mysterious givers of legal opinion in some way connected with
>> > organisations who have always been against the Bill?
>> [snip]
>>
>> Even if they are, that does not imply that their legal opinion was
>> influenced by their opposition to the bill.
>
>And likewise the opinions of Government law officers were not influenced
>by their support for the Bill, QED.
So you agree that the governments law officers are not impartial towards the
bill. :-)
When two views are mutually contradictory at least one must be wrong. The
inability of the minister to address the specific questions put to him by
the House of Commons Select committee [see other thread] shows fairly
clearly that it doesn't pass the Human Rights test.
As has been pointed out in another thread "a section 19 certificate has two
functions one overt, and one which arises by implication.
The overt function is to confirm that, in the relevant Minister's opinion,
the Bill is compatible with the HRA. This doesn't bind the courts in any
way - since the final decision on compatibility is theirs.
The implied function though is to inform the courts that Parliament
*intended* the Act to be compatible with the HRA - so that if there is any
reasonable way of interpreting the Act so as to retain compatibility with
the HRA, then the courts should so interpret it."
The important point here is that the section 19 certificate is merely a
statement about the *Minister's* opinion. In issuing it, he is free to
ignore any advise put to him by his own advisors. [In any case, that advise
is confidential, so he can claim it to be whatever he wants. The true facts
will never emerge to haunt him during his political career]. That is why the
issuing of a certificate is meaningless, it is a statement about the biased
opinion of a minister. It would be hard to find an opinion that carried less
legal weight.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: any public-key algorithm
Date: Wed, 31 May 2000 17:58:18 -0700
Eric Verheul wrote:
> > I also didn't understand the key size comparisons, where you
> > claim XTR is competitive with ECC. You compare XTR over GF(p^6)
> > to ECC over GF(p), where p is around 2^170. ISTM an EC public
> > key is 170+1=171 bits plus whatever is needed for shared
> > parameters. But XTR need at least 1 (and maybe 3) elements
> > of GF(p^2), so at least 340 bits are needed, plus shared
> > parameters. So I don't see how XTR is competitive unless you
> > always send the shared parameters.
> Then I suggest you start reading the paper. BTW keys in ECC are 340 bits
> too, unless you want to do a square root caclulation each time...
Yes, do a square root each time if you want low bandwidth.
It's not so crazy -- it is what your own paper suggests in
the 2nd sentence of the 2nd paragraph of sect. 4.4.
After coming here to sci.crypt to promote XTR, I am surprised
that you are not more willing to defend your paper.
The comparisons to RSA and ECC in sect. 4.4 are interesting,
but comparisons to DH and DH-LUC would be more to the point
because that is what XTR is closely related to. Why didn't
you put in those comparisons?
------------------------------
Date: Thu, 01 Jun 2000 00:24:47 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: No-Key Encryption
=====BEGIN PGP SIGNED MESSAGE=====
Bryan Olson wrote:
> We can build [variants of Shamir's Three Pass protocol] from
> an invertible associative operation, call it *, as:
>
> ----- k1 * x ----->
>
> <-- k1 * x * k2 ----
>
> ----- x * k2 ------>
[...]
> Suppose we limit ourselves to the associative operation
> case. Does there exist an associative operation "*" such
> that the protocol illustrated above is secure?
No. Proof:
For * to be associative and invertible, we must have two operations
on some set S:
* : S x S -> S
/ : S x S -> S
such that (a * b) * c = a * (b * c), and (a * b) / b = a
for all a, b, c in S.
Case 1: * is commutative
((k1 * x) * (x * k2))/((k1 * x) * k2)
= ((x * k1) * (x * k2))/((k1 * x) * k2) [commutativity of *]
= (x * (k1 * x * k2))/(k1 * x * k2) [associativity of *]
= x [(a * b) / b = a]
Case 2: * is not commutative
In this case, in order for the protocol to work properly, it
requires another operation
\ : S x S -> S
such that a \ (a * b) = b. Then:
(((k1 * x) * k2)/(x * k2))\(k1 * x)
= ((k1 * (x * k2))/(x * k2))\(k1 * x) [associativity of *]
= k1\(k1 * x) [(a * b) / b = a]
= x [a \ (a * b) = b]
In either case, a passive eavesdropper can get the key.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOTWeyTkCAxeYt5gVAQGgdAf/ZPSeZ2WgJ0UsBVgphP3Ndn1zBBBnD5Ie
HEEHvDR0LButy8jIok3EzeBFouu8IzkDM47qsR8t3qvueY2NIv+yHdapnS3GQ16L
BDluO1k4fMD9ErmsYPMpIv85rzNWhzH2+R3DB8G8w4SpobHyDRKnNUDTFXD/2vY+
nrht2hLgHDLpNifAO7SoFEy4dBIM8PqzncAWTPCIwoNdUpBYpGUeEb5+xkleyJCA
okZe5JLXGIx1ri0Lab1n0vQfaUJDsOkpSJxghPftKGMyFr2GSQIgRUzefMEClAlV
f3CHo+vS8+a2zHJyeV5ILWsRMFh009bCSVNyv29vc5lHkVaAlb18Dw==
=kpgd
=====END PGP SIGNATURE=====
------------------------------
Date: Thu, 01 Jun 2000 03:22:44 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Compare 3DES's.
=====BEGIN PGP SIGNED MESSAGE=====
Paul Schlyter wrote:
> In article <8g4lqn$1eb$[EMAIL PROTECTED]>,
> William Rowden <[EMAIL PROTECTED]> wrote:
> > . How is CBC mode defined for 3DES? According to the sci.crypt FAQ,
> > only ECB is defined for 3DES.
>
> While there's no official CBC 3DES definition, [...]
FIPS 46-3 (http://www.itl.nist.gov/div897/pubs/fip46-3.htm) has an
official definition of outer-CBC 3DES.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOTXI0jkCAxeYt5gVAQGh5gf8DLEg4zfp8QFZfuVUrLyeulKneOo5x/LN
j16rGRtGdSqNrCPx0T7veid9++H9vqk3QltQUNf9KOgSqM26huScJkvaX2OXT2zJ
p3AcyW+LKGsJcdv/SJGQ8BvvYyryJZf0+eMGdtmi8r0Y1qb38FZfNFjyaHnQwWZA
Vg97lKNHTTVocjiHKH571tlLrx9GLFlD4omuKQk5K5vr065T8HGePo3FcdjozYUB
Mfp9XHr8X0iGCF1k5NfUUyErhnrfER/WUJkgz/d9q+qHQ2fg1GCerYR6ARpLvjCR
+Eo4ESrRsqSq7y2j0CEMs/p8w5h4cAOgxyGD5VUq9llWB0/uer2OWw==
=Am+m
=====END PGP SIGNATURE=====
------------------------------
From: Joaquim Southby <[EMAIL PROTECTED]>
Subject: Re: Is OTP unbreakable?
Date: 1 Jun 2000 02:46:16 GMT
In article <[EMAIL PROTECTED]> Tim Tyler, [EMAIL PROTECTED] writes:
>I don't agree with the spirit of any of this. For example are you
>considering that you can jam a receiver, to prevent the original message
>being received? The scenario does not depend on transmission down cables.
>
If you jam the receiver, wouldn't that be a clue that something was
afoot? Would you necessarily know where the receiver is located or are
you discussing some sort of wide-area jamming? What effect does this
jamming have on *your* receiver or, for that matter, the transmitter?
The scenario depends on the interceptor being able to grab the message
AND prevent it from reaching the intended recipient without the recipient
being aware of the theft.
>I feel you're in danger of under-estimating your potential adversaries.
>
>If you're working in security and are actually trying to protect
>something of value, I believe it can sometimes help to try to
>*over*-estimate the abilities of your adversaries, to give your systems
>some safety margin, in case your estimate of their resources was in error.
>
My estimates always assume that the adversaries are smarter, richer, and
better-looking than me. I always assume that they have the resources to
counter every thing I myself can devise. I assume that if someone wants
a secret badly enough, they can get it. I consider the worth of the
secret vs. the cost of protecting it and the cost of detecting it. The
protection I use for that secret is calculated to cost the adversary
enough that he chooses to look for the secret elsewhere.
In such an effort, I would consider as many aspects of the situation as I
could imagine, including the media through which the secret passes from
sender to receiver. Interlocking layers of security would be employed
not only to protect the original secret from attacks, but also to protect
the countermeasures against those attacks from counter-countermeasures.
This process would recur until vanishing returns set in. (I'm trying to
assure you that, although my cryto knowledge does not approach the level
of most of the posters here, I do have bona fides and experience in
protecting secrets.)
The point I am arguing is that the original scenario discounted OTP
because of what I believe is a limited set of circumstances. The
scenario did not say that the circumstances were limited; implying that
OTP has some sort of fatal fault in every situation. This is not the
author's fault; he is probably nowhere near as anal-retentive as I am and
simply didn't see the need to expound on every exception. However,
someone reading that message who is still on the low end of the crypto
learning curve could come away with the impression that OTP should not be
used.
>After all, there are probably some pretty damn powerful adversaries out
>there - though /hopefully/ they won't be interested in your traffic ;-)
>
Agreed, and they are almost certainly not interested in my traffic given
the quality of information I usually post here.
------------------------------
From: Joaquim Southby <[EMAIL PROTECTED]>
Subject: Re: Is OTP unbreakable?
Date: 1 Jun 2000 03:02:05 GMT
In article <[EMAIL PROTECTED]> Trevor L. Jackson,
[EMAIL PROTECTED] writes:
>These claims may be based on a limited view of the opportunities an
>interceptor has. Consider that many comm techniques have a more sophisticated
>infrastructure than a pair of tin cans connected by string. For example,
>simple radio broadcasts imply that every message can, in principle, be
>received by every listener. But who is the "listener"? Is it the radio
>operator of the captain? The radio operator isn't really a listener, but more
>a part of the infrastructure. He will ignore or discard traffic not aimed at
>a a listener on his ship.
>
>This means that changing a digit in a message header from PT109 to PT106 would
>be the equivalent of blocking the message because the intended recipient does
>not get the message.
>Network switches and routers perform this kind of filtering all the time.
>Even (especially) on broadcast messages as opposed to point-to-point traffic.
>
The assumption made by the original poster was that the original message
was stopped from reaching the intended recipient. If I read your
suggestion correctly, you are proposing intercepting a message, changing
a header to fool the recipient, and then transmitting the changed message.
1) What about the original message? Did the recipient get it? I don't
see how your scheme would block that.
2) If you change the header and send the altered message, how does this
fool PT109 into accepting the message as valid if he ignores it? You've
blocked the altered message, not the valid one.
BTW, I'm still talking about traditional radio/TV broadcasting, not
broadcast network messages.
------------------------------
** 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
******************************
