Cryptography-Digest Digest #997, Volume #10 Fri, 28 Jan 00 22:13:01 EST
Contents:
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: Clock drift (was Intel 810 chipset Random Number Generator) (Michael Kagalenko)
How to password protect files on distribution CD ([EMAIL PROTECTED])
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: Clock drift (was Intel 810 chipset Random Number Generator) (Michael Kagalenko)
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: How to password protect files on distribution CD (Theo de Raadt)
Re: How much does it cost to share knowledge? (David A Molnar)
Re: How to password protect files on distribution CD (NFN NMI L.)
Re: Intel 810 chipset Random Number Generator ("james d. hunter")
Re: How to password protect files on distribution CD (GJJ)
Re: *** ECC Strong and Weak combined ("Harvey Rook")
Re: "Trusted" CA - Oxymoron? ("Brian Hetrick")
Re: Pencil & paper cipher question (David Wagner)
Re: Pencil & paper cipher question ("r.e.s.")
Re: designing secure backdoors into the system (Thierry Moreau)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Michael Kagalenko)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 29 Jan 2000 00:02:29 GMT
Reply-To: [EMAIL PROTECTED]
Guy Macon ([EMAIL PROTECTED]) wrote
]In article <86qqvg$l1o$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
](Michael Kagalenko) wrote:
]
]> Again nope. This cycle-by-cycle period variation produces clock drift,
]> which grows with time. Precisely how it does so can be evaluated using
]> fluctuation-dissipation theorem. If I feel like it, I might even do
]> the computation one day.
]
]This flies in the face of my 20 years of experience as an Electronics
]Engineer, including working with high precision time references at
]Odetics and CD/DVD jitter measuring circuits at Disc Manufacturing, Inc.
You did not see what I describe because you weren't looking for it.
The good place to look would be metrology publications.
]What causes clock drift (two clocks with diverging ansers as to what
]time it is) is simply the difference between the actual and desired
]frequency.
That is one reason. The other reason is the presense of dissipation
in resonant system, or, in other words, wide resonance curve. Atomic
clocks are more precise because they make use of very narrow resonance
curves.
] Easy to correct for.
Then why GPS satellites bother with atomic clocks ? Just get
some thermostabilized and recalibrated quartz clocks.
] What causes the frequency to drift
]is the physical aging of the crystal.
That's much slower process than thermal drift.
] If it was caused by a brownian
]style drift caused by jitter (what you call "cycle-by-cycle period
]variation"), the frequency would reset when I turned off the
]electronics overnight.
You don't understand the point I am making. The frequency doesn't
get "reset" if you turn off the circuit. In fact, average
frequency does not change. I estimate I said that 5 times or so already.
] Brownian motion of particles has memory (the
]position of the particle).
Precisely wrong. Brownian motion has no "memory" of any kind.
] Crystal clock frequency has no memory;
]the frequncy is derived on the spot from various electrical and
]mechanical factors.
]
------------------------------
From: [EMAIL PROTECTED] (Michael Kagalenko)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 29 Jan 2000 00:07:06 GMT
Reply-To: [EMAIL PROTECTED]
Guy Macon ([EMAIL PROTECTED]) wrote
]In article <86qreo$mr7$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
](Michael Kagalenko) wrote:
]>
]>Trevor Jackson, III ([EMAIL PROTECTED]) wrote
]
]>]Further, you are assuming that clock drift is unpredictable.
]>]This is simply invalid.
]>
]> No. You are wrong. Since quartz crystals have mechanical losses, they
]> will have thermal noise, for the same mathematical reason that
]> resistor has thermal noise.
]
]No one has disagreed with this.
No one showed any signs of having understood this.
] What the problem is is that this is
]a third or fourth order effect, completly swamped by predictable
]sources of variation.
We can discuss the magnitude of the thermal clock drift once there
is an agreement that the effect exists. So far, everyone opposing me
in this thread that it does not exist at all, not that it is small.
]>] Given a small sample of measurements it is straightforward to
]>]extrapolate the drift. That means it is predictable. That means it isn't
]>]random. That means your argument fails.
]>
]> No, - it means that you a) did not read my post, where I said that
]> systematic drift can and should be eliminated
]> b) do not understand why random noise will produce truly random clock
]> drift.
]
]Sure, if you PERFECTLY identify EVERY SINGLE predictable component
]of the drift and PEFECTLY correct for EVERY ONE, what you have left
]is by definition, unpredictable. This is like tossing a two headed
]coin and correcting for the bias by calling H-T a one, T-H a zero, and
]discarding all H-H and T-T results. In theory this gives you a random
]bitstream. In practice the bitstream is a quite predictable lack
]of output bits.
I am not interested in discussing coin tosses. So far, you seem to
have finally acknowledged that simply counting the number of quartz
cycles per time interval (measured by more precise means) can
allow to recover truly random data. You seem to be backtracking on your
earlier flat denial that this happens, and now claim that it is simply
too small to be measured. This latter position is not correct
either, but we'll get to that.
------------------------------
From: [EMAIL PROTECTED] (Michael Kagalenko)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 29 Jan 2000 00:08:48 GMT
Reply-To: [EMAIL PROTECTED]
Guy Macon ([EMAIL PROTECTED]) wrote
]In article <86qrom$hck$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
](Michael Kagalenko) wrote:
]
]> You did not show that you undestand my argument, which has
]> to do with clock drift originating from thermally random (meaning,
]> resulting from quartz's coupling to thermodynamical reservoir, as per
]> fluctuation-disspation theorem) noise.
]
]If fluctuation-disspation theorem leads you to believe that crystals
]act in ways that I can see with my own eyes they don't, then either
]fluctuation-disspation theorem is wrong or YOU don't understand it.
]Tell me, have you ever looked at the signal coming from a crystal
]with a jitter test set? Done a spectrum analysis of the signal?
]performed long term tests with multiple crystals? Hooked an
]oscilloscope or frequency counter to a Crystal? I have, and I
]assure you that Crytal oscillators don't act the way you think
]that they do.
]
You did not see the effect that I described because you were not looking
for it. Try reading some books on metrology.
------------------------------
From: [EMAIL PROTECTED] (Michael Kagalenko)
Crossposted-To: sci.physics
Subject: Re: Clock drift (was Intel 810 chipset Random Number Generator)
Date: 29 Jan 2000 00:13:50 GMT
Reply-To: [EMAIL PROTECTED]
Sandy Harris ([EMAIL PROTECTED]) wrote
][EMAIL PROTECTED] (Michael Kagalenko) spake thus:
]
]> ... So far, no one evinced any signs of having
]> understood what I am saying in plain English over and over and over.
]
]I'm coming in to this discussion late.
]
]From here it looks as though you're advocating at least three clearly
]nonsensical propositions:
]
] 1) clock drift has enough randomness to be interesting for
] cryptographic purposes
Not quite. The specific kind of clock drift does. What kind
was explained several times, so I am nto going to repeat just for you.
Dejanews has my earlier posts.
]
] 2) a protocol involving connections to an Internet time server
] can be secure enough to trust for cryptographically important
] random numbers
Yep. In every mechanism of random data generation you have to trust
something.
] 3) IPSEC or other cryptography can solve problem 2
]
]Ritter and Schryver appear to have understood you completely and to have
]demolished your first two points rather thoroughly. If anyone is failing to
]understand, it seems to be you.
Neither Ritter not Schriver understood me, and all their objections are wide off
the mark.
]As for your third point, it traps you in a vicious circle. IPSEC and most
]other cryptographic protocols require random numbers. If you need IPSEC
]to generate your random numbers, you're sunk.
Nope. The faxt is that measuring clock drift gives an additional source
of randomness. That it may not be enough does not change my main point;
that the thermal clock drift exist, that it can be measured, and that it
can be used to produce truly random numbers. You anothers seem to
be switching from the argument that effect does not exist to the
argument that it impractical to use it. I welcome the advance in
your understanding.
]I'd suggest you read RFC 1750 and mull over it a while.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp,comp.security.unix,comp.security
Subject: How to password protect files on distribution CD
Date: Sat, 29 Jan 2000 00:20:40 GMT
Hi
We have developed some software and we want to ship them on CD
in encrypted form to our customers. Then we want to give them some keys
to decrypt the software. We should be able to generate the passwords
for our customers. We might want to put further restrictions on
encryption and authorization in the future but not now.
What software do I need to use for this? If this is irrelevant to this
group, please point me to the correct one.
Thank you
ZZ
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Michael Kagalenko)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 29 Jan 2000 00:20:33 GMT
Reply-To: [EMAIL PROTECTED]
Scott Nelson ([EMAIL PROTECTED]) wrote
]On 28 Jan 2000 (Michael Kagalenko) wrote:
]
]> More important is the disagreement about what kind of noise I am
]> talking about.
]>
]Why is that important?
Because so far, I see the denials that the well-nown physical
effect exists. You have a little flat-earth society here at sci.crypt.
It's not surprising; most of the participants here never took graduate
level course in Statistical physics.
------------------------------
From: [EMAIL PROTECTED] (Michael Kagalenko)
Crossposted-To: sci.physics
Subject: Re: Clock drift (was Intel 810 chipset Random Number Generator)
Date: 29 Jan 2000 00:15:14 GMT
Reply-To: [EMAIL PROTECTED]
Michael Sierchio ([EMAIL PROTECTED]) wrote
]Sandy Harris wrote:
]
]> Ritter and Schryver appear to have understood you completely and to have
]> demolished your first two points rather thoroughly. If anyone is failing to
]> understand, it seems to be you.
]
]Precisely.
]
]Anyone with half as much brainpower as confidence knows that these two fellows
]have earned their chops and have studied the matter. I would treat an
]admonishment from either of them as an act of grandmotherly kindness, and
]leave it at that.
Thier alleged experience fails to instill in me any awe, considering
blatant and obvious errors they make in every reply to my posts.
------------------------------
From: [EMAIL PROTECTED] (Michael Kagalenko)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 29 Jan 2000 00:17:42 GMT
Reply-To: [EMAIL PROTECTED]
Guy Macon ([EMAIL PROTECTED]) wrote
]In article <86qsmh$pkc$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
](Michael Kagalenko) wrote:
]
]> That means that you have not understood the physics of Brownian
]> random walk. Please, re-read the lectures once again, this time
]> paying attention.
]
]PU-LEEZE... There is no amount of understanding of the physics of
]Brownian random walks that in any way leads to the conclusion that
]this is how crystals behave. Do you have any evidence that they do?
]No. Do I have evidence for my claims? Yes. Eye witness testimony
]and a large body of electronics research that you have never
]bothered to read.
Well, once again, the claims that you make are incorrect. The thermal
drift that I am speaking of exists.
]I can tell you why you are wrong. You have failed to understand
]the effect of increased international travel on language diversity.
]Once you become an expert on this you will see that quartz crysyals
]don't act the way you think they do. If you disagree with me, it's
]because you don't know enough sociology and linguistics. Do your
]homework. Please, retake your classes in these subjects once again,
]this time paying attention.
]
]See? I can do it too!
]
You may have an experience in Electrical engineering, however , you
do not understand statistical physics required to appreciate my point.
It's as simple as that.
------------------------------
Crossposted-To: alt.security.pgp,comp.security.unix,comp.security
Subject: Re: How to password protect files on distribution CD
From: Theo de Raadt <[EMAIL PROTECTED]>
Date: 28 Jan 2000 17:46:47 -0700
[EMAIL PROTECTED] writes:
> We have developed some software and we want to ship them on CD
> in encrypted form to our customers. Then we want to give them some keys
> to decrypt the software. We should be able to generate the passwords
> for our customers. We might want to put further restrictions on
> encryption and authorization in the future but not now.
>
> What software do I need to use for this? If this is irrelevant to this
> group, please point me to the correct one.
Consider using CSS.
Just kidding; sorry, I had to, I couldn't resist!
--
This space not left unintentionally unblank. [EMAIL PROTECTED]
Open Source means some restrictions apply, limits are placed, often quite
severe. Free Software has _no_ serious restrictions. OpenBSD is Free Software.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: How much does it cost to share knowledge?
Date: 29 Jan 2000 00:55:35 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> Well I try to keep myself busy (I write software (ask me if you want to
> find out what I write)) but I am at a lost to what I should look at
> with my interests...
What do you mean by "what I should look at" ? which books? which
university courses? which projects ?
Thanks
-David
------------------------------
From: [EMAIL PROTECTED] (NFN NMI L.)
Subject: Re: How to password protect files on distribution CD
Date: 29 Jan 2000 01:05:14 GMT
<<We have developed some software and we want to ship them on CD
in encrypted form to our customers. Then we want to give them some keys
to decrypt the software. We should be able to generate the passwords
for our customers. We might want to put further restrictions on
encryption and authorization in the future but not now.>>
Copy protection, right? Sigh.
Anyways, how could you generate a password for your customer (probably based on
their name, sigh) AFTER a CD is stamped out?
S.T.L.
------------------------------
From: "james d. hunter" <[EMAIL PROTECTED]>
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: Fri, 28 Jan 2000 20:23:18 -0500
Reply-To: [EMAIL PROTECTED]
Michael Kagalenko wrote:
>
> Guy Macon ([EMAIL PROTECTED]) wrote
> ]In article <86qsmh$pkc$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> ](Michael Kagalenko) wrote:
> ]
> ]> That means that you have not understood the physics of Brownian
> ]> random walk. Please, re-read the lectures once again, this time
> ]> paying attention.
> ]
> ]PU-LEEZE... There is no amount of understanding of the physics of
> ]Brownian random walks that in any way leads to the conclusion that
> ]this is how crystals behave. Do you have any evidence that they do?
> ]No. Do I have evidence for my claims? Yes. Eye witness testimony
> ]and a large body of electronics research that you have never
> ]bothered to read.
>
> Well, once again, the claims that you make are incorrect. The thermal
> drift that I am speaking of exists.
>
> ]I can tell you why you are wrong. You have failed to understand
> ]the effect of increased international travel on language diversity.
> ]Once you become an expert on this you will see that quartz crysyals
> ]don't act the way you think they do. If you disagree with me, it's
> ]because you don't know enough sociology and linguistics. Do your
> ]homework. Please, retake your classes in these subjects once again,
> ]this time paying attention.
> ]
> ]See? I can do it too!
> ]
>
> You may have an experience in Electrical engineering, however , you
> do not understand statistical physics required to appreciate my
point.
> It's as simple as that.
Since statistical physics is simple math, do you understand
the experimental physics required to -prove- your point.
------------------------------
From: GJJ <[EMAIL PROTECTED]>
Subject: Re: How to password protect files on distribution CD
Crossposted-To: alt.security.pgp,comp.security.unix,comp.security
Date: Fri, 28 Jan 2000 18:02:17 -0800
I always see a number of ads in the monthly "Software Development"
magazine (http://www.sdmagazine.com). Here are a few:
Crypkey Copy Protection and License Control
Kenonic Controls Ltd., Calgary, Canada
(403) 258-6200 Fax: (403) 258-6201
http://www.crypkey.com
e-mail: [EMAIL PROTECTED]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
WIBU-KEY - The high quality protection system for high quality software
North America:
Griffin Technologies, LLC
(800) 986-6578 FAX: (785) 832-8787
http://www.griftech.com
e-mail: [EMAIL PROTECTED]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
HASP - NSTL tried and tested! Does more than protect your software.
Aladdin Knowledge Systems Inc.
(800) 223-4277 (212) 564-5678 FAX: (212) 564-3377
http://aks.com/swdev
e-mail: [EMAIL PROTECTED]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Ultimate Software Security (i.e. STOPCOPY family, STOPVIEW,
NETLIMIT)
BBI Computer Systems, Inc.
(800) TRY-ABBI (301) 871-1094 FAX: (301) 460-7545
http://www.bbics.com
e-mail: [EMAIL PROTECTED]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sentinel products for electronic license distribution, anti-piracy
Rainbow Technologies
(949) 450-7300 (800) 852-8569 FAX: (949) 450-7450
http://www.rainbow.com
e-mail: [EMAIL PROTECTED]
______________________________________________________________
BTW - I have no personal or professional interests in the above
companies and have not tried any of their products so I can't vouch for
them...
HTH.
GJJ
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: "Harvey Rook" <[EMAIL PROTECTED]>
Subject: Re: *** ECC Strong and Weak combined
Date: Fri, 28 Jan 2000 13:48:06 -0800
This depends strongly on the protocol you are using. If a client ever sends
or receives message that is not doubly encrypted by the servers key, then
you have reduced the amount of work needed for a brute force attack by
2^(0.80*KeyLen) If you are using a 256 bit ECC key, the brute force work is
2^51. Such a small key can be brute forced with today's hardware
[EMAIL PROTECTED]
"Greg" <[EMAIL PROTECTED]> wrote in message
news:86o2jl$6ba$[EMAIL PROTECTED]...
> I was doing some testing recently with my ECC code and I noticed
> that if I have a curve over a large field and a key that has the
> most significant bit set, it takes about one second to complete
> a point operation.
>
> Yet, if I keep the key value very small where, say, the 80% MSBs
> are clear, then the operation is very fast. This makes me think
> that given a very strong public key for a server, a client can
> use a random small private key which can be used to quickly generate
> both the client's public key and shared secret. The client side
> is very fast on these operations because its private key is
> small. The client's public point is then sent to the server
> and the server performs a point operation of its own to derive
> the same shared secret.
>
> While the server takes as long as usual, the benefits of this
> strategy (limiting the client private key size) include:
>
> Faster client key setup
> Faster client secret setup
> Weak secret does not weaken server public key
>
> Any thoughts?
>
> --
> The only vote that you waste is the one you never wanted to make.
> RICO- we were told it was a necessary surrender of our civil liberties.
> Asset Forfeiture- the latest inevitable result of RICO.
> http://www.ciphermax.com/book
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: "Brian Hetrick" <[EMAIL PROTECTED]>
Crossposted-To:
alt.privacy,alt.security.pgp,comp.security.pgp,comp.security.pgp.discuss
Subject: Re: "Trusted" CA - Oxymoron?
Date: Sat, 29 Jan 2000 02:21:37 GMT
"Jim Bennett" wrote ...
> THAWTE (www.thawte.com)- Your identity must be vouched for by a
> group of people whom Thawte has determined are trustworthy. How
> does Thawte determine this? If you have had your identity vouched
> for a selected number of times by different people, you are
> considered capable of vouching for other people's identity. Better
> than Verisign, but not much. A group of several co-conspirators
> could vouch for false identities for each other fairly easily.
> Value: still not good enough for a high value transaction.
[Disclaimer: I am a Thawte "notary," and so arguably am not entirely
impartial in this issue.]
True, but then neither is any other "proof" of identity in common use.
Actually, come to think of it, in the highest value transactions in
which I have engaged (buying and mortgaging a house, getting married,
getting divorced :-), etc.), I have never been asked to show
identification. But false identification documents are, I understand,
easy enough to come by.
What the Thawte web of trust does do, however, is establish a chain of
liability. Thawte issues a certificate based on the word of notaries
whose identities are known. The notaries agree to keep copies of the
identity documents they used in establishing identities for five
years. Suppose Thawte issues a certificate that is eventually shown
to be for a false identity. Thawte calls in the notaries who attested
to the identity: either they can pull out copies of documents, or they
cannot. If the notaries can produce copies of documents, then (i)
Thawte can demonstrate they used reasonable prudence in issuing the
certificate and (ii) the person who trusted the certificate is in
exactly the same situation as having trusted more traditional forms of
identification. If the notaries cannot produce copies of documents,
they get to try to convince a court of their lack of liability. This
is a fairly strong reason for notaries to attempt to avoid randomly
attesting identities. A false identity can be tied back to the
notaries that attested that identity; if those notaries were
themselves false identities, _they_ can in turn be tied back to the
notaries who attested to them; and so forth.
Could a group of co-conspirators cause Thawte to certify a false
identity? Yes. Could they do so without exposing themselves to
liability? No. I suspect it would be substantially easier to falsify
more traditional identity proofs -- which, under any CA scheme, could
then be used to generate credentials.
Assuring someone's identity is a hard problem, one that humanity has,
despite thousands of years of effort, yet to solve in the "real
world." Expecting the "digital world" to have a better solution to a
real world problem than the real world itself is, I suspect, somewhat
overoptimistic.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Pencil & paper cipher question
Date: 28 Jan 2000 18:41:17 -0800
Ok, so let's assume for the moment that the initial fill of the
"shift register" with digits can be made sufficiently secure (hard to guess).
That may rule out exhaustive keysearch attacks, but how do you know there
are aren't clever attacks that treat VIC as a LFSR with nonlinear output?
There's been a lot of progress in the open literature on cracking such ciphers
(e.g., correlation attacks).
Moreover, we may expect that the military is even better at cracking
LFSR-based ciphers than the academic community is, because it is rumored
that most military ciphers are (or were) shift-register based.
Do these observations shake confidence in VIC?
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Pencil & paper cipher question
Date: Fri, 28 Jan 2000 18:44:57 -0800
"Salvatore Sanfilippo" ...
[...]
: About pencil & paper ciphers I'm looking for a way to sign
: (using only pencil & paper) the message, a simple hash
: algorithm. For example using solitaire you are subjected to
: "man in the middle known ciphertext attack", and the receiver
: will not be able to detect this attack.
According to
http://www.io.com/~ritter/GLOSSARY.HTM#ManInTheMiddleAttack
that would not be true for shared secret keys:
"It is interesting to note that, regardless of how inconvenient
it may be to share keys for a secret-key cipher, this is an
inherent authentication which prevents MITM attacks."
I notice, however, that the background image on John Savard's
web page concerning the VIC cipher (which I think is supposed to
be a sample of actual ciphertext from microfilm) shows, at the
bottom of a 1035-digit message, the notation "No. 12740/622".
A checksum, or what?
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: Thierry Moreau <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: designing secure backdoors into the system
Date: Fri, 28 Jan 2000 21:40:11 -0500
Yusuf Motiwala wrote:
>
> Hi,
>
> I would like to design a secure backdoor for a system so that in
> imergency situation
> one can access the system (for example, forgoten the password). However,
> what I
> would like to do is that:
>
> - even I (designer) can not access the same backdoor without proper
> information.
> Hence backdoor should be dependednt on may be product serial number,
> MAC
> address etc.
> - there should be some secure method so that admin who had once access
> to the
> backdoor can not use it again once he/she loose the admininistration
> control over
> the system for example, he/she left the job
>
> In there any crypto technique to design such a secure backdoor. Is it
> possible to have completely secure backdoor? I will appreciate any
> pointers to
> resources/links/publications related to designing the same.
>
> Regards,
> Yusuf
Maybe you might re-state your requirements as follows:
You have a device in the field ... (a secure device with an
authentication key)
... for some reason, the current key is no longer valid ... (key lost or
a suspected key disclosure)
... then you want to re-key the device and keep the level of
authentication "reasonable" (a "still trustworthy" super-administrator
would revoke the privileges of a "once trustworthy" device administrator
and grant privileges to someone else, a "newly trustworthy"
administrator).
I studied this problem for key management for POS (point-of-sales)
terminals and came up with a scheme where re-keying is necessarily done
by two persons, respectively the "newly trustworthy" administrator, and
some database administrator (a POS network is controlled from a central
location). The procedure features mutual authentication through an
out-of-band channel and certainty that the authentication key is not
spoofed while the authentication steps proceed as expected.
------------------------------
** 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
******************************
