Cryptography-Digest Digest #875, Volume #12 Sun, 8 Oct 00 21:13:01 EDT
Contents:
Re: Dense feedback polynomials for LFSR ("bubba")
Re: Why trust root CAs ? ("Lyalc")
Re: education where ???please help (David A Molnar)
Internet Security Question ("Tony")
Re: Why trust root CAs ? ("Lyalc")
Re: A new paper claiming P=NP (Paul Rubin)
Re: Internet Security Question (Paul Rubin)
Re: FTL Computation ("Paul Lutus")
Re: NSA quote on AES (John Savard)
Re: Why wasn't MARS chosen as AES? (John Savard)
Re: Need help: considerations for IV and Keysetup (those who know me have no need of
my name)
----------------------------------------------------------------------------
From: "bubba" <[EMAIL PROTECTED]>
Subject: Re: Dense feedback polynomials for LFSR
Date: Sun, 08 Oct 2000 22:24:53 GMT
Yes, choose your length, say 100 bits and a dense starting point,
say 0x1ABCDEF1234567890ABCDEF012. To find the next
100 primitive polynomials, use:
ppsearch128 bits=100 hex poly=0x1ABCDEF1234567890ABCDEF012 search=100
(from http://sduplichan.home.att.net/primitive/primitivePolynomials.htm)
to get:
1ABCDEF1234567890ABCDEF02F
1ABCDEF1234567890ABCDEF0D5
1ABCDEF1234567890ABCDEF13F
1ABCDEF1234567890ABCDEF141
1ABCDEF1234567890ABCDEF385
1ABCDEF1234567890ABCDEF391
1ABCDEF1234567890ABCDEF573
1ABCDEF1234567890ABCDEF5D5
1ABCDEF1234567890ABCDEF72B
1ABCDEF1234567890ABCDEF7E1
1ABCDEF1234567890ABCDEF81D
1ABCDEF1234567890ABCDEF877
1ABCDEF1234567890ABCDEF97F
1ABCDEF1234567890ABCDEFAEF
1ABCDEF1234567890ABCDEFB93
1ABCDEF1234567890ABCDEFBED
1ABCDEF1234567890ABCDEFC8F
1ABCDEF1234567890ABCDEFC9D
1ABCDEF1234567890ABCDEFCDF
1ABCDEF1234567890ABCDEFDDB
1ABCDEF1234567890ABCDEFF43
1ABCDEF1234567890ABCDEFF75
1ABCDEF1234567890ABCDF008D
1ABCDEF1234567890ABCDF00D7
1ABCDEF1234567890ABCDF0161
1ABCDEF1234567890ABCDF019D
1ABCDEF1234567890ABCDF038B
1ABCDEF1234567890ABCDF03B1
1ABCDEF1234567890ABCDF052D
1ABCDEF1234567890ABCDF0669
1ABCDEF1234567890ABCDF0AE7
1ABCDEF1234567890ABCDF0B45
1ABCDEF1234567890ABCDF0DCD
1ABCDEF1234567890ABCDF0E5B
1ABCDEF1234567890ABCDF0EDF
1ABCDEF1234567890ABCDF0F0F
1ABCDEF1234567890ABCDF0FC5
1ABCDEF1234567890ABCDF105D
1ABCDEF1234567890ABCDF11CF
1ABCDEF1234567890ABCDF128B
1ABCDEF1234567890ABCDF14EB
.
.
.
"Simon Johnson" <[EMAIL PROTECTED]> wrote in message
news:8rqhcv$elg$[EMAIL PROTECTED]...
> Anyone got a decent method of dense finding primitive mod 2 for use in
> an LFSR? Does the method in 'Applied Cryptography' work?
>
> --
> Hi, i'm the signuture virus,
> help me spread by copying me into Signiture File
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Why trust root CAs ?
Date: Mon, 9 Oct 2000 09:27:43 +1000
Yes, a major issue with CAs and certificates is the need to physically
attend a place to prove that you do have a specific identity.
It costs banks about $50 - $100 to enrol new customers (staff, counter time
etc). I expect the same or more ofr issuing certificates.
Lyal
nospam wrote in message <8rp4qj$qeb$[EMAIL PROTECTED]>...
>We (a Chicago-based co-op) have been considering running our own non-profit
CA.
>The biggest obstacle is, to verify the information submitted with a CSR is
not
>inexpensive.
>
>If we just promiscuously sign every request submitted, our CA cannot be
>trusted. If we go to the same extremes to validate submissions as Verisign,
>our rates will be high.
>
>For the moment the goal is to only sign keys for people we know personally,
>which means the CA will only really be useful within our circle of friends,
>a relatively small community.
>
>
>In article <eMoD5.416654$[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]> wrote:
>>So, I can discover snakeoil CA's procedures for verifying bogus.com,
>>and assure myself that they have checked out bogus.com.
>>But how can I trust snakeoil CA itself ?
>
>You have to trust somebody, the root CA's are trustworthy only in that they
>are big businesses with a strong incentive to take care in verifying the
>entity to which they issue the certificate is actually who it claims to be,
>and in protecting their signing key.
>
>
>>Is there a chain of trust from any institution that I might trust,
>>such as my bank, back to the root CAs ?
>
>No, and that brings up the real question- why should you trust these
specific
>issuers of certificates, and no others? Why should you NOT trust web
servers
>with self-signed keys?
>
>To some extent, I might be MORE comfortable with a server using a key
signed
>by a bank based in Switzerland, operating under their secrecy laws.
>
>
>>Is there any reason, apart from the fact that they've been operating for
>>a number of years now and AFAIK nothing's gone wrong, for us all to trust
>>the root CAs ? Apart from a general lack of trust leading the the end
>>of e-civilization as we know it ?
>
>There's no reason not to trust them, they do take pains to ensure that they
>do not issue a certificate for 'www.nationalbank.com' to a web server that
>is actually operated by a malicious third party.
>
>
>>As a non-US citizen, I have a slight problem with most of the CAs and
browser
>>vendors being US corporations. If I were a member of some organization
>>or country that the US regards as an enemy (Libya, Iraq ??) I might have
>>a more serious problem with it.
>
>So start your own root CA in your nation. There's nothing to stop you,
though
>you may have difficulty getting Netscape and IE to include a Libyian key
>server in their standard browser distribution.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: education where ???please help
Date: 8 Oct 2000 22:24:51 GMT
Simon Johnson <[EMAIL PROTECTED]> wrote:
> In article <8rqd3m$pl6$[EMAIL PROTECTED]>,
> "simon" <[EMAIL PROTECTED]> wrote:
>> dear group i live in surrey uk and wish to learn about cryptography
>> but i cannot find anywhere that offers any courses please could
> anybody
>> point me in a direction
>> i would be very grateful
>> SIMON P.........................
>>
>>
> Yeah, i've been looking for a university course in cryptography. To be
> honest i don't think there are any at undergraduate level. (maybe i'm
> not looking hardenough') Prehaps we should write our own syllabus. :P
Avi Rubin keeps a list of courses on cryptography at
http://avirubin.com/courses.html
You may find some insight there.
-David
------------------------------
Reply-To: "Tony" <[EMAIL PROTECTED]>
From: "Tony" <[EMAIL PROTECTED]>
Subject: Internet Security Question
Date: Sun, 8 Oct 2000 23:46:03 +0100
Hi,
I have a problem with a particular website. When I click on register I am
sent to a secure server. I am supposed to enter details here and click
send. However, when I double click on the padlock on Internet Explorer 5 &
5.5, instead of telling me about the server certificate and the secure
connection it says "This certificate has failed to verify for all of it's
intended purposes". This message is a bit vague but to me it says there is
a problem with the security, probably to do with the authentication
process. Can anyone tell me exactly what it means?
I talked with the technical support people there and he said that my
browser didn't have the right Certificate Authority certificate that the
server certificate needed. He said that this didn't matter because the ISP
then sends a temporary certificate to my computer and allows the completely
secure connection to be established. To me this sounds a little dubious.
How secure is this transfer of the CA certificate from ISP to my computer?
To be honest I don't know what these "Trusted Root Certification
Authorities" certificates actually are or what their purpose is. I presume
they are basically the Public Key of the each trusted Certification
Authority.
As I understood it, the browser has built into it single public key of a
root CA. The browser can therefore establish a secure connection with a
site that has a server certificate issued by that CA. The browser can
establish a secure connection servers that have certificates issued by
other CAs by the use of a certification hierarchy, where the root CA issues
a certificate for another CA and that CA can issue a certificate for
another CA and so on. When you connect to a site all the certificates
in-between their certificate and the root CA are sent by the secure server.
What I would like to know is, is this the case, and what are all these
"Trusted Root Certification Authorities" certificates are for?
Thanks,
T.
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Why trust root CAs ?
Date: Mon, 9 Oct 2000 09:44:55 +1000
An electronic signature related to a specific purchase order has no inherent
relationship to an electronic signature on the transaction paying for that
order. That's how business is today, and neither CAs nor certs are going to
change that anytime soon.
A certificate issued by your bank has no meaning when it comes to your
ability to send an email or be bound by the email's contents, apart from
saying "person X is known to us and has an account". What's in it for the
bank? The bank has the same liability, added infrstructure to operate and
no cost savings. Why would a bank be a CA?
Trusting Root CAs:
Well, you can only trust them as much as you trust your software - no more.
If a false "CA Root" cert is inserted into the CA Cert store (perhaps by any
unpatched browser flaw that allows file manippulation or root access), then
any certificate signed by that false CA will be trusted by your machine.
Will you check the CA trust chain and CRL for every cert you receive?
If not, then you rely on the trust you place in your machine, not the CA.
Lyal
Daniel James wrote in message ...
>In article <1kQD5.22093$[EMAIL PROTECTED]>, Lyalc wrote:
>> 1. In the smartcard scenario described below, a symmetric key does the
>> exact same job (card+PIN = proof of identity)
>
>If we state that the customer trusts the bank not to falsify payment
>instructions, that there is no need for the veracity of the payment
>instructions to be checked by any party other than the bank, and that there
is
>no desire to provide the customer with a signing key for any other purpose
>than signing payment instructions that will be verified only at the bank
then,
>yes, you're quite right.
>
>Using a public key system makes it possible for the trader (who can be made
>aware of the customer's public key, but would not be aware of a secret key
>used in a siilar way) to check the signature and reject bogus payments
without
>having to trouble the bank, using certificates makes it possible for the
>trader to have confidence that the customer's public key has not been
spoofed.
>
>The system I have outlined also provides the customer with a public keyset
>that can be used for other purposes (signing EMail, etc.) which I perceive
as
>a benefit that could not be derived from a secret key system.
>
>> 2. The bank does have a liability to the customer when it enrols the
>> customer and issues the card for an acocunt. The terms and conditions
>> contratually oblige the bank to act on the account holders instructions
(or
>> an authorised proxy - usually demmed someone who knows the PIN and has
the
>> full card details). No one else's. An Acquirer bank (ie anyone who
>> acquires a payment message for clearing and settlement, which may be a
bank)
>> has little liability, except to the issuer largely, who expects the
acquirer
>> to transport the transaction and authentication information securely and
>> with integrity.
>
>The terms and conditions offered by a bank are defined by the bank, and are
>set when the customer and the bank enter into a contract. There isn't any
>legal requirement for the bank to indemnify the customer against fraud and
>there is no requirement for the bank to do so - unless/until such a
contract
>is signed. Banks can and do change the terms and conditions of credit card
>accounts and the customer has the right to change banks if he doesn't like
the
>terms. As I said - it currently suits the banks to offer that indemnity as
>part of their service, if that changes you can be sure that they will stop
>offering it.
>
>> Confidence with electronic payments today comes from trusting your bank,
the
>> merchant's bank, and the merchant. Adding a CA to this process means
>> everyone has to trust more elements - the Issuer's CA, the Merchant CA,
the
>> Acquirers CA, and any CAs these entities trust.
>
>Absolutely - and the credit card company, as well. What I should perhaps
have
>spelt out more clearly was that I was proposing that the bank - or, in
fact,
>the credit card company - should *BE* a CA. You express your trust in your
>bank when you open an account and deposit your money with them, you need
>express no greater degree of trust when you allow them to sign certificates
>for keys that are to be used to authorize your manipulation of that
account.
>(It would require a bit more trust to then use the bank-certified keys for
>other purposes, but youcan choose not to do that.)
>
>> If you already trust each other, do you need to prove it from scratch
(with
>> the entire CA process from registration to digital signature) or just
>> provide a relaible short form reference to that trust relationship?
>
>No. That's not what PKI buys you, though. If I trust my bank, and my bank
>trusts your bank, and your bank trusts you, then I can feel that - at least
as
>far as banking is concerned - I can trust you. PKI provides a mechanism
>whereby that trust can be communocated securely between all the parties
>involved where there are more than 2 parties.
>
>If you turn out not to be trustworthy I can turn to my bank and complain
that
>they represented you as trustworthy, they can turn to your bank and say the
>same, and your bank knows who you are and can exact retribution.
>
>If PKI were properly applied to eCommerce the customer would be required to
>send a digitally signed order to the trader and the trader would be
required
>to send a digitally signed order acknowledgement back to the customer. Each
of
>these signatures could be verified by the receiving party and by the banks
>concerned. In jurisdictions where digital signatures have legal force these
>signed packets will constitute a contract for sale and the customer will
have
>/legally acceptable/ proof of the order's acceptance and /legal/ redress
>against the trader if the order is not met. Trust is still involved, yes -
all
>parties concerned have to trust the financial institutions and the
financial
>instsutions have to trust each other - but this is nothing new, this is a
>fundamental requirement for any sort of commerce and eCommerce doesn't
change
>a thing.
>
>I do take your point that the technology has to work, too, and that there
are
>attacks that can be carried out to subvert digital signatures; but the same
is
>true for written signatures and, again, nothing is really new.
>
>Going back to the original poster's question - "why trust root CAs?" - I
>suppose my take on this is that there isn't any reason to trust a CA while
>that CA is a disinterested party, so it's a good question. I do think,
though,
>that PKI technology has a lot to offer, and I think that what will make it
>start to work in the real world is certificates being issued by
insitutions -
>like banks and credit card companies - who have a vested interest in
providing
>a secure environment for their own businesses, and with whom we all deal
every
>day of our lives.
>
>Cheers,
> Daniel.
>
>
>
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Crossposted-To: comp.theory,sci.math,sci.op-research
Subject: Re: A new paper claiming P=NP
Date: 08 Oct 2000 15:48:58 -0700
Any chance of providing a pdf file? The .ps.zip and .ps.gz files are
hard to view in a browser.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Internet Security Question
Date: 08 Oct 2000 16:03:54 -0700
"Tony" <[EMAIL PROTECTED]> writes:
> Hi,
>
> I have a problem with a particular website. When I click on register I am
> sent to a secure server. I am supposed to enter details here and click
> send. However, when I double click on the padlock on Internet Explorer 5 &
> 5.5, instead of telling me about the server certificate and the secure
> connection it says "This certificate has failed to verify for all of it's
> intended purposes". This message is a bit vague but to me it says there is
> a problem with the security, probably to do with the authentication
> process. Can anyone tell me exactly what it means?
What site is it? There is a known bug between MSIE and certain Verisign
SGC certificates. IE shows that error but it doesn't mean anything.
If you post the URL, I'll check it. Or if you look at the certification
path, and it's something like
Verisign Public CA
\_ Verisign International CA
\_ site certificate
then that's what you're seeing. I figured out the details of the
problem once but don't remember them. Basically the certificate is
marked as certifying web sites (which is fine, and which is what you
want) and also for some other thing that its CA is not marked for.
If you're really worried, call Verisign customer service and ask them
to explain it to you.
------------------------------
From: "Paul Lutus" <[EMAIL PROTECTED]>
Crossposted-To: sci.astro,sci.physics.relativity,sci.math
Subject: Re: FTL Computation
Date: Sun, 08 Oct 2000 23:05:20 GMT
ca314159 <[EMAIL PROTECTED]> wrote in message
news:8rqm4p$i7f$[EMAIL PROTECTED]...
> In article <eI2E5.18527$[EMAIL PROTECTED]>,
> "Paul Lutus" <[EMAIL PROTECTED]> wrote:
> > therefore the burden of proof is on you
>
> You mean the burden of _disproof_ is on me;
> unless of course, all of a sudden you are
> uncertain about your own position and spinning
> your reference frame around and around ...
No, the term "burden of proof" is the correct one. If we are speaking of a
scientific theory, one can only support it with evidence, but you did not
pose a theory, you just made an unsupported statement. In this case, "burden
of proof" is the correct term.
Your assertion is a positive one -- that FTL is possible -- therefore yours
is a burden of proof.
Had you posed a theory in which it is possible (you did not do this) then it
would be a burden of evidence.
Had you asserted that FTL was not possible, you might be said to have a
burden of disproof, but this is an unlikely burden in science.
So it is a burden of proof, because you simply asserted it was possible,
without reference to theory.
--
Paul Lutus
www.arachnoid.com
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NSA quote on AES
Date: Mon, 09 Oct 2000 00:38:49 GMT
On Sat, 7 Oct 2000 13:32:46 -0700, "Scott Fluhrer"
<[EMAIL PROTECTED]> wrote, in part:
>UBCHI2 <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> Let's see a definitive statement that they can't break the AES.
>Why should they bother? Would anyone believe them?
A good point.
However, if the NSA were to break precedent, and issue a statement
saying that they found out there *is* a crack to Rijndael, and thus it
cannot be safely used by the U.S. Government for SBU purposes...
*that* would be believed. Even if they were to plead classification as
a reason for not supplying the proof that, of course, can be supplied
for such statements.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Why wasn't MARS chosen as AES?
Date: Mon, 09 Oct 2000 00:34:32 GMT
On Sun, 08 Oct 2000 19:42:00 GMT, JCA <[EMAIL PROTECTED]> wrote, in
part:
>Roger Schlafly wrote:
>> JCA wrote:
>> > ? Why wasn't MARS chosen as AES?
>> > Because it was the worst candidate by a mile?
>> It was designed by a committee at IBM.
> My comment was a somewhat tongue-in-cheek
>one, and so may be yours. In case it isn't, the fact
>that there is a big company behind it doesn't
>guarantee its quality.
Yes, there is the old saying about a camel being a horse designed by a
committee.
Seriously, it was good in some ways, but Rijndael was good in the ways
that were considered important.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: Need help: considerations for IV and Keysetup
Date: Mon, 09 Oct 2000 01:06:18 -0000
<8rk1sm$p0i$[EMAIL PROTECTED]> divulged:
>Eric, of course it wouldn't be a good thing for a company to have its
>sysadmin leave without first telling the password of the encrypted
>tapes. Why would the sysadmin possibly do that?
consider death then. or perhaps it's kept (securely one would hope) in a
pda, which is then lost.
key escrow is the way to go.
>To use my tape encryption addon, the user needs to have full access
>privileges in winNT,
you might consider rethinking this aspect -- or not, as you wish.
>I agree that you have a serious problem if you backup kiddy porn,
think instead "corporate secrets," as in "must not be reveiled if at all
possible."
(besides eric mentioned kitty porn, which i assume only appeals to
felines.)
--
okay, have a sig then
------------------------------
** 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
******************************
