Cryptography-Digest Digest #990, Volume #12 Mon, 23 Oct 00 21:13:01 EDT
Contents:
Re: xor algorithm ([EMAIL PROTECTED])
A naive question (Mok-Kong Shen)
Re: How to post absolutely anything on the Internet anonymously (Tim Tyler)
Timestamping ("Kevin Crosbie")
Re: Timestamping (David Schwartz)
Re: Why trust root CAs ? ("Lyalc")
Re: byte != octet [was: Re: Rijndael implementations ] (Mok-Kong Shen)
Re: A naive question (John Savard)
Re: new to data encryption please help (John Savard)
Re: Why trust root CAs ? (Anne & Lynn Wheeler)
Re: Why trust root CAs ? (Anne & Lynn Wheeler)
Re: Why trust root CAs ? (Anne & Lynn Wheeler)
Re: Hypercube/FFT encryption (Terry Ritter)
Re: Why trust root CAs ? (Anne & Lynn Wheeler)
Re: On block encryption processing with intermediate permutations (Bryan Olson)
Re: A new paper claiming P=NP (Matt Kennel)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: xor algorithm
Date: 23 Oct 2000 22:10:35 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Sundial Services) wrote:
> Certainly any stream-cipher worth its salt must be tested to be sure
> that, if it -is- run backward, it will not be more vulnerable to
> analysis than when it is run "the right way."
For instance a class of weak keys that can be determined by running RC4
backwards until the initial table setting is found?
Keith
http://www.cix.co.uk/~klockstone
------------------------
'Unwise a grave for Arthur'
-- The Black Book of Carmarthen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: A naive question
Date: Tue, 24 Oct 2000 00:25:15 +0200
Is there anything wrong with the following?
Let there be a master key Q. To send message blocks P
with a sufficiently strong algorithm E, we pick a random
number R, obtain K = E(Q,R) and send R and blocks E(K,P)
to the recipient.
Thanks.
M. K. Shen
------------------------------
Crossposted-To: talk.politics.crypto,alt.freespeech
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: How to post absolutely anything on the Internet anonymously
Reply-To: [EMAIL PROTECTED]
Date: Mon, 23 Oct 2000 22:12:30 GMT
In sci.crypt Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> They could just make running Publis illegal. There will have to be some
:> ofther compelling use for - it besides cocking a snook at the government -
:> to prevent this strategy from being applied.
I know what that "compelling use will be": it will be distributing
paedophile material and child pornography in a manner that evades
prosecution. Obviously such unamerican activities should not be
permitted.
:> Anonymity and privacy seem destined to go the way of the Dodo. When the
:> government's nano-scale spy robots are everywhere, escaping from their
:> view long enough to do anything in private will be very, very difficult.
: Then you accept the total destruction of the US Constitution and our
: way of life?
I don't see how much in the way of privacy can continue. Perhaps if a
"benevolent" government closes its eyes to the activities of its citizens.
I can't see why any government would do that, though - it goes beyond
benevolence into stupidity, IMO.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ ILOVEYOU.
------------------------------
From: "Kevin Crosbie" <[EMAIL PROTECTED]>
Subject: Timestamping
Date: 23 Oct 2000 22:58:18 GMT
Hi all,
I am writing a program to sign some data, and I wanted to add a timestamp to
this. I figure that I just hash the signed data that I have, and send that
off to a notary service, they attach their signature and public key, and
sent it back, allowing me to verify that it was timestamped at that time.
Does anyone know of a good free service which does that, or if not, some
service which does that for a fee.
Thanks a million,
Kevin
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Timestamping
Date: Mon, 23 Oct 2000 16:05:20 -0700
Kevin Crosbie wrote:
>
> Hi all,
>
> I am writing a program to sign some data, and I wanted to add a timestamp to
> this. I figure that I just hash the signed data that I have, and send that
> off to a notary service, they attach their signature and public key, and
> sent it back, allowing me to verify that it was timestamped at that time.
>
> Does anyone know of a good free service which does that, or if not, some
> service which does that for a fee.
Verisign has a timestamp server that's freely available. The protocol
for using it is one of the PKIX standards, but it's a PITA. I don't know
of any libraries to make this easier.
DS
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Why trust root CAs ?
Date: Tue, 24 Oct 2000 10:15:21 +1000
The lesson to learn from SET is that the back end cost (although large) is
miniscule to the enormous "front end' cost of an entriely duplicated, new
authentication infrastructure that doesn't make enough real difference.
Tor Rustad wrote in message ...
>"Anne & Lynn Wheeler" <[EMAIL PROTECTED]> wrote in message
>> Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes:
>> > there is a mapping of x9.59 to iso8583 (i.e. payment cards, debit,
>> > credit, etc)
>>
>> one of the issues in mapping digital signatures to the existing
>> payment infrastructure and providing end-to-end authentication ... was
>> the typical 8583 message was 60-100 bytes. It was possible to map the
>> additional x9.59 fields and a ec/dss into something like an additional
>> 80 bytes or so (nearly doubling message size for authentication).
>
>I'm reading your posts with interest, and will look into some of your links
>on this matter. I must admit that I have not paid attention to X9.59. In
>SET, the ISO8583 mapping is implemented already, why do we need another way
>to do this? To open up for on-line debet card transactions?
>
>As long as the card companies allow no security via credit cards, and the
>banks earn more mony (in some countries) on credit card transactions, the
>business case for implementing X9.59 doesn't look good. Also, _if_ X9.59
>mandates new messages at the ASN.1 level, this will be expensive to
>implement. Futhermore, some of us are starting to get really fed up with
all
>these PKI standards...
>
>> A certificate-based infrastructure represented two approaches ...
>>
>> 1) use certificates in an internet-only mode and truncate them at
>> boundary between the internet and the financial infrastructure. The
>> downside was giving up on basic security tenets like end-to-end
>> integrity and end-to-end authentication.
>
>That is the way things are done in the real world.
>
>> 2) carry the certificate ... but compress it into a manageable mode.
>
>No, no learn from SET, we don't want to implement a new back-end for all
the
>banks and card companies. Proper security and audit at the Payment GW is
>sufficient.
>
>> Now, some things cropped up:
>
><snip>
>
>Many want to make return of investment on SET. Unless the card companies
>drop SET, that is still the way to go for interoperability beyond national
>schemes. For the moment, we will only look into using PKI for on-line
>banking and bill-presentment.
>
>--
>Tor
>
>
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: byte != octet [was: Re: Rijndael implementations ]
Date: Tue, 24 Oct 2000 01:43:22 +0200
John Savard wrote:
>
> The trouble with using the term 'character', of course, is that some
> modes of representing characters are variable-length. A term like
> 'character cell' or 'storage cell' or just 'cell' would probably be
> more readily understood than attempting to use 'byte' for the purpose
> it officially has in the C standards.
It may be of interest to note that he Fortran standard
doesn't use the term byte at all but has the terms character
storage unit, numerical storage unit and unspecified storage
unit.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: A naive question
Date: Mon, 23 Oct 2000 23:32:04 GMT
On Tue, 24 Oct 2000 00:25:15 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>Is there anything wrong with the following?
>Let there be a master key Q. To send message blocks P
>with a sufficiently strong algorithm E, we pick a random
>number R, obtain K = E(Q,R) and send R and blocks E(K,P)
>to the recipient.
Given that E(Q,R) means "R, encrypted with key Q", there is nothing
wrong with that, although it is more conventional to send K and blocks
E(R,P) to the recipient. In that case, Q is called the "key-exchange
key".
It is a standard practice, and useful in reducing the number of times
one has to use time-consuming public-key algorithms.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: new to data encryption please help
Date: Mon, 23 Oct 2000 23:34:53 GMT
On Mon, 23 Oct 2000 02:53:45 GMT, [EMAIL PROTECTED] wrote, in
part:
> i would like to know any online references for beginners and if
>possible books .
At least there are some books in the stores right now. Simon Singh's
"The Code Book" - and another one less well recommended - are now out
in paperback. Find whatever your local library has; I know in my city,
books on this fascinating topic tend to wear out quickly at the
library.
My web site, although far from perfect, has lots of fascinating
details on many cipher systems, starting from paper and pencil ones,
and going up to the present day.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Subject: Re: Why trust root CAs ?
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Tue, 24 Oct 2000 00:03:09 GMT
"Tor Rustad" <[EMAIL PROTECTED]> writes:
> I'm reading your posts with interest, and will look into some of your links
> on this matter. I must admit that I have not paid attention to X9.59. In
> SET, the ISO8583 mapping is implemented already, why do we need another way
> to do this? To open up for on-line debet card transactions?
>
> As long as the card companies allow no security via credit cards, and the
> banks earn more mony (in some countries) on credit card transactions, the
> business case for implementing X9.59 doesn't look good. Also, _if_ X9.59
> mandates new messages at the ASN.1 level, this will be expensive to
> implement. Futhermore, some of us are starting to get really fed up with all
> these PKI standards...
there is existing fraud ... even w/o the internet.
SET didn't provide end-to-end authentication. It truncated
authentication at the SET payment gateway and then generated an
acquiring financial infrastructure transaction with a flag indicating
authentication ... which eventually got to the customer's issueing
financial institution.
Two years ago, somebody from VISA gave a presentation at an ISO
meeting regarding the number of (SET) transactions coming into
consumer issuing financial institutions with the SET authenticated
flag turned on ... and they could show that there was no SET
technology involved in the transaction (issue crops up in security
infrastructures when there isn't end-to-end authentication and
end-to-end integrity).
The X9.59 mapping to ISO8583 is done in much the same way that the SET
mapping was done ... find a place in the existing ISO8583 message
definition to stash the information ... so that ISO8583 doesn't have
to be changed (although the 8583 work group now has a new field being
defined that would specifically support this function).
If you note that the X9.59 standard doesn't really define messages
... it defines a set of fields formated for digital signature signing
and authentication. It specifically doesn't say how the fields are
transmitted on an end-to-end basis ... it just defines how the fields
have to be formated when they are signed and how the fields have to be
formated when the signature is verified. In this sense, it took a
similar approach to that of FSTC ( http://www.fstc.org &
http://www.echeck.org ) for digitally signed electronic checks (the
transmitted messages carrying the fields may bear absolutely no
resemblance to the format of the fields for signing and
authentication). And in fact, with minor changes, the X9.59 definition
(if translated to XML/FSML encoding) is useable for echeck (i.e. the
charter given the X9A10 work group was to preserve the integrity of
the financial infrastructure for all electronic retail account-based
payment transactions with a digital signature).
The industry has regular message and software upgrades ... some of
them dictated by regulations ... and more than a quite a few changes
that are orders of magnitude larger change compared to what is needed
for x9.59. The resources needed to effect the X9.59 changes, if
scheduled as part of standard industry change process ... might not
even show up as a real line item (lost in the noise of business as
usual).
Standard business case applies to X9.59 ... benefits outweight the
costs. Done as part of normal business, the technology, development,
and deployment costs of X9.59 can be managed into the noise range. As
cited in previous postings ... those costs however are totally dwarfed
by costs of deploying real live customer call center support for new
kinds of technology transactions.
One of the issues with X9.59 is that it has been defined as part of
the industry financial standards process ... for implementation as
part of standard production operation. In order to achieve end-to-end
integrity, it doesn't define toy pilots that might be do'able for $50k
where the authentication and integrity may be stripped off at the
internet boundary (as an aside, development, test, deployment and
training for one new screen in a customer call center can easily be
more than the cost of a toy pilot ... the real costs for new kinds of
technology is how to provide customer support ... if done correctly,
the technology issues can be managed into the noise range).
So what are compelling business issues for end-to-end authentication
and integrity ... along with fraud & risk reduction?
--
Anne & Lynn Wheeler | [EMAIL PROTECTED]
http://www.garlic.com/~lynn/
------------------------------
Subject: Re: Why trust root CAs ?
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Tue, 24 Oct 2000 00:14:51 GMT
[EMAIL PROTECTED] (Vernon Schryver) writes:
> What's the big deal about +/- 60-180 bytes on the wire?
> Yes, I realize that multiplying umptyzillion transactions per day by 60
> bytes amounts to a lot of bits per second, but modern network performance
> is determined to the first order by the number of packets, not the number
> of bytes or the sizes of packets.
>
> It costs the same (for all reasonable meanings of "cost") to send
> a packet containing 80, 160, or 180 bytes on a modern network, with
> the possible but quite implausible exceptions of some radio-telephone
> and low speed modem links.
>
> Part of the reason for that is network traffic is so extremely bursty
> ("self-similar") that you must over-provision, or your customers get
> unhappy because sometimes their dirty HTTP pictures take longer to appear.
the issue is relying on existing infrastructure ... built around the
80-160 byte messages. FOr instance, I've seen reports that SET
certificates ranged in size from 2k bytes to a high of 12kbytes.
Part of the X9.59 work was that it could be mapped to a brand new
network where all the bandwidth rules have totally changed ... and it
wasn't necessary to worry about existing practical concerns. So at at
the 100,000 foot level ... does a definition also carry as a
prerequisite that brand-new financial infrastructure be built in order
to support its deployment.
However, part of the X9.59 work was also to see how it could be mapped
to existing ISO8583 financial networks where there are real bandwidth
rules and transactions size issues ... and still provide end-to-end
integrity and end-to-end authentication.
Part of the charter given the X9A10 work group was to preserve the
integrity of the financial infrastructure for all electronic retail
account-based payments with a digital signature. "All" would include
all the existing financial infrastructures as well as the new ones
that haven't been built and deployed yet (i.e. the charter wasn't to
define an internet only solution or a new network only solution, it
was a solution for all electronic retail account-based payments).
It is believed that the same X9.59 definition can be made to work in
both kinds of environments (the existing financial infrastructures as
well as the new infrastructures that haven't been built yet).
there is a line someplace about, in theory there is no difference
between theory and practice, but in practice there is.
--
Anne & Lynn Wheeler | [EMAIL PROTECTED]
http://www.garlic.com/~lynn/
------------------------------
Subject: Re: Why trust root CAs ?
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Tue, 24 Oct 2000 00:35:23 GMT
Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes:
> there is a line someplace about, in theory there is no difference
> between theory and practice, but in practice there is.
and besides ... it is superfulous and redundant to transmit a copy of
something (and appended transaction certificate) possibly thousands of
times a day ... to somebody that has the original. Even HTTP browswers
know about caching and trying to avoid superfulous and redundant
transmission.
--
Anne & Lynn Wheeler | [EMAIL PROTECTED]
http://www.garlic.com/~lynn/
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Hypercube/FFT encryption
Date: Tue, 24 Oct 2000 00:33:36 GMT
On Mon, 23 Oct 2000 15:16:54 -0500, in
<[EMAIL PROTECTED]>, in sci.crypt James Felling
<[EMAIL PROTECTED]> wrote:
>>
>> PS to Ritter, in one of your docs, you say that with 1 plaintext /
>> ciphertext pair, you can probably uniquely identify a DES key... I
>> believe the actual number required is 3 pt/ct pairs.
>>
>
><snip>
>What you say is true in one sense, and what he says is true in annother.
>3pt/ct is the MAXIMUM ammount required. However, typically 1pt/ct pair will be
>enough to do so, 3 merely confirms it beyond the shaddow of a doubt.
That depends on what size of shadow you need for doubt.
There is no end to the abstract possibility that, at random, some
false key will produce the desired first block transformation, that
same key will produce the desired second block transformation, and so
on. So even 3 pairs does not "confirm it beyond the shadow of doubt."
There *is* no "beyond . . . doubt," there is just, very, very, very,
very, very unlikely.
In practice, none of this is an issue.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
Subject: Re: Why trust root CAs ?
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Tue, 24 Oct 2000 00:39:57 GMT
Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes:
> authentication). And in fact, with minor changes, the X9.59 definition
> (if translated to XML/FSML encoding) is useable for echeck (i.e. the
> charter given the X9A10 work group was to preserve the integrity of
> the financial infrastructure for all electronic retail account-based
> payment transactions with a digital signature).
one of the FSML issues was the lack of deterministic encoding rules in
standard markup language definitions. In the possibility that the
fields in a signed object ... are not transmitted in the signed object
bit representation ... the recepient has to be able to exactly
recreate the original object bit representation (in order to verify
the signature) from the transmitted fields (regardless of how they are
transmitted). The authenticating entity needed to follow the same
deterministic (markup language) encoding rules in recreating the
signed object that were followed by the signer when the original
orject was created (for signing).
--
Anne & Lynn Wheeler | [EMAIL PROTECTED]
http://www.garlic.com/~lynn/
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Tue, 24 Oct 2000 00:30:44 GMT
Mok-Kong Shen wrote:
>
> Bryan Olson wrote:
> > Again I agree. In the long history of this thread, that was
> > the basic line of my first attack. That attack depends upon
> > each chosen message being encrypted using the same
> > permutations. Shen now requires a constantly-updating PRNG
> > state to generate the permutations.
>
> I am very surprised by the word 'now' above. I answered
> in a post to Tom St Denis that the PRNG is not to be
> reset and that correspondence was before we start debating
> with each other.
I see only that you had stated it is not reset in a single
session. I believe it was after my first attack that you
wrote of storing the state at the end of one session for use
in the next. Further, your proposal included one method of
generating the permutation that seemed to enable the attack.
Perhaps the clearest statement of the issue is from your post
of September 29:
[Olson:]
| > I assumed the attacker could get the same permutation in
| > different messages. Your only specific suggestion of how
| > the PRNG is seeded divided the message in half and used each
| > half to determine the permutation for the other, which is
| > obviously repeatable in a chosen plaintext attack. If the
| > attacker cannot re-start the PRNG, then choosing all blocks
| > of x the same, except the block that differs from x', looks
| > like a promising tactic.
[Shen:]
| In my original post, I first said of using a PRNG,
| which I intend not to reseed (see answer to Tom St. Denis),
| i.e. the permutations are different for different messages.
| That would pose some difficulty to attack, if I correctly
| understand what you wrote above. But I also mentioned
| using one half of the result of the previous cycle to
| permute the other half and vice versa as an alternative
| means of doing the permutation. This alternative is
| certainly poor under your chosen plaintext attack.
In any case my second attack assumes a new set of random
permutation for each message. (It does not really follow the
"promising tactic" I mentioned in the quote above.)
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Matt Kennel)
Crossposted-To: comp.theory,sci.math,sci.op-research
Subject: Re: A new paper claiming P=NP
Date: Tue, 24 Oct 2000 01:03:12 +0000 (UTC)
Reply-To: mbkennel@<REMOVE THE BAD DOMAIN>yahoo.spam-B-gone.com
On 11 Oct 2000 07:14:16 GMT, Bill Unruh <[EMAIL PROTECTED]> wrote:
:In <[EMAIL PROTECTED]> glenn <[EMAIL PROTECTED]> writes:
:
:>Irrelevant question, but is there any way of converting a pdf file to
:>ps?
:
:pdf2ps
:Both are Unix programs available with many Linux distributions. They
:were apparently written by Adobe or adobe people, so may well be
:available on other platforms. Alternatively, Acroread will produce a ps
:file from a pdf file ( just "print to file" as a postscript printer).
:xpdf will also do it.
Perhaps P = NP or P /= NP, but I believe we have proved for sure
that, at least for computer scientists, PS /= PDF and apparently
there is no bijective mapping between any elements of either set that
they can find. :)
--
* Matthew B. Kennel/Institute for Nonlinear Science, UCSD
*
* "To chill, or to pop a cap in my dome, whoomp! there it is."
* Hamlet, Fresh Prince of Denmark.
------------------------------
** 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
******************************
