Cryptography-Digest Digest #810, Volume #10 Wed, 29 Dec 99 23:13:01 EST
Contents:
Re: Attacks on a PKI ("Lyal Collins")
Maybe I'm just blind, or maybe just stupid ("Joseph Ashwood")
Re: Attacks on a PKI (Anne & Lynn Wheeler)
Re: HD encryption passphrase cracked! (Guy Macon)
Re: Video card reconfiguration (Guy Macon)
Re: Secure Delete Not Smart ("Trevor Jackson, III")
Re: Cryptography in Tom Clancy ("Trevor Jackson, III")
Re: More idiot "security problems" ([EMAIL PROTECTED])
Re: Attacks on a PKI (Greg)
Re: AES wise? ([EMAIL PROTECTED])
Re: Attacks on a PKI (Greg)
Re: SSL And Certificate Verifications (Greg)
Re: SSL And Certificate Verifications (Paul Rubin)
Re: Attacks on a PKI (Paul Rubin)
----------------------------------------------------------------------------
From: "Lyal Collins" <[EMAIL PROTECTED]>
Subject: Re: Attacks on a PKI
Date: Thu, 30 Dec 1999 11:12:18 +1100
I have yet to see such a simple policy approach address what I call the 30 -
1million issue.
i.e.
Why should the rules for 30 people doing $1m transactions be different from
those for 1 million people doing $30 transactions?
The overall business/systemic risks are approxiamently equivalent.
All PKI "rules" or 'policies' need to be common - otherwise the low-dollar
value user commmunity will not adopt the technology (or worse, discard it
once an adverse court case occurs, or once problems surface in big numbers,
as they assuredly will), forcing much higher costs onto the
high-value-users.
End result - uneconomic technology for the sake of it, not for any
fundamental imporvement of business or security - the latter does not sell
unless there is a fundamental reason to buy it.
Lyal
Timothy M. Metzinger wrote in message
<[EMAIL PROTECTED]>...
>>> Authentication of individuals using PKI is about as strong as the
passwords
>>> they use to control access to their priate key.
>>>
>>> Why not stick to passwords and integrity checking databases, for
>>> non-ecommerce uses?
>
>The Wheeler's already covered most of this, but let me reinforce the point.
>
>The strength and reliability (key factors in "trust) of a PKI are (assuming
>good software) generally driven by a couple of non-software issues.
>
>The protection against tampering of the CA, which includes physical and
>personnel security.
>
>The protection against misuse or compromise of the individual private key.
>This can be addressed by policy (requiring a complex passphrase for access)
or
>technology (140-3 key storage devices)
>
>The beauty of PKI is that you can have certificate policies that specify
the
>"value" of the certificate(s) and the necessary protection given to them,
i.e.:
>
>For transactions having a value up to $500, a PIN is all that's necessary
to
>unlock the private key, and it can be completely contained on a PC.
>
>For transactions between $500 and $10000, the key can be contained on a PC
but
>the passphrase must be complex.
>
>For transactions between $10000 and $100000, there must be two factor
>authentication to allow access to the key, which can be stored on the PC.
>
>For transactions between $100000 and $1000000, you must store the key on a
>smart card, and a complex passphrase is required for access (still two
>factors).
>
>For transactions over $1000000, they key must be stored in a 140-3 device,
and
>a complex passphrase or biometrics must be the other factor.
>
>I just made these policies up, but you can see that there are ways to
manage
>the risk of a compromised private key.
>
>
>Tim Metzinger
>Timothy Metzinger
>Private Pilot - ASEL - IA!!!! AOPA Project Pilot Mentor
>DOD # 1854 '82 Virago 750 - "Siobhan"
>Cessnas, Tampicos, Tobagos, and Trinidads at FDK
>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Maybe I'm just blind, or maybe just stupid
Date: Wed, 29 Dec 1999 17:14:46 -0800
Now I know we're all rather against the inexperienced/unpublished posting
new algorithms. But I've had this one kicking around my head for a few years
now, and I haven't made much progress (see after algorithm), and I haven't
been able to find a reference regarding it's use or analysis. With that said
let me say that I have come up with other ideas but upon my examination I
found them either lacking or that someone else had the idea first. Now on to
the entertainment.
I have spent quite a bit of time trying to express this in something
readable (and ended up with pseudocode) and I'm still not sure if it's any
good, please feel free to ask, also the algorithm is slower than it could
be. It is very slow in software, but very fast in hardware ( <10 ns per
block in TTL). I am deliberately being arbitrary about the numbers because
I'm fairly sure that an attack on one length if quite likely to be
applicable to large blocks/keys. I am only presenting the minimal function
because it lends itself to analysism, and can be repeated easily.
type mappedchar { subkey, originalLocation }
function encrypt(datain, keyin)
array of mappedchar key
array of subblock data
array of subblock dataout
parse keyin into n equally sized subkeys, place subkeys in key[].subkey
place location number in key[].originalLocation (eg key[1].originalLocation
= 1)
parse datain into n equally sized subblocks, place in data[]
(1)sort key by subkey
for i from 0 to n
dataout[i] = data[key[i].originalLocation]
examples (I've chosen key/data/subkey count to align on bytes, but it's not
necessary)
#1
32-bit key and data
4 subkeys/blocks
key: bmjf
data: when
subkeys = b m j f
subdata = w h e n
subkeys{
b 1
m 2
j 3
f 4
}
(point 1)
subkeys{
b 1
f 4
j 3
m 2
}
dataout = wneh
#2
64 bit key
64 bit data
8 subkey
key: djtfdlhg
data: lambmeat
subkeys = d j t f d p h g
subdata = l a m b m e a t
subkeys{
d 1
j 2
t 3
f 4
d 5
p 6
h 7
g 8
}
(point 1)
subkeys{
d 1
d 5
f 4
g 8
h 7
j 2
p 6
t 3
}
dataout = lmbtaaem
My analysis:
The security is based on two things, the non-invertability of a sort, and
the difficulty of solving a totally arbitrary anagram. The security of the
first is to my knowledge absolute, it is impossible to invert a sort of
arbitrary data. The second however the furthest I have gotten in general is
that humans can obviously solve anagrams faster than the O(n!) algorithm
that is obvious, and we can also seemingly solve them in O(unpredictable)
time, meaning that regardless of the length the solution may be immediate or
may come in O(n!) time.
Another issue is the very large number identity keys, for example just a 2
subkey, one byte each, using only lowercase characters from the english
language (ie a-z), there are over 300 of them. A few examples are
aa
ab
ac
ad
ae
Following closely is the large number of keys that result in the same
output.
Then there is the issue of the fact that it is extremely "leaky", there is a
massive amount of information that is leaked out of the round, and also the
lack of one bit changing in the plaintext changing more than one bit of the
output.
Given all of this I think it can be potentially be useful to aid in the
dispersion of a cipher (it provides arbitrary dispersion). I can honestly
see no other real use than that, although it may provide leverage to aid in
compression (or non-compressibility).
Given enough rounds and the addition of another type of round it may be
useful. It may be helpful to change the subblock size, say ranging from
1-bit to 1/2-block. Additional rounds can also be performed faster than the
first because the array can be stored already sorted, leading to an
encryption time of O(n).
Timing:
the setup time is O(nlogn), each block takes O(n) time.
Joseph
------------------------------
Subject: Re: Attacks on a PKI
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Thu, 30 Dec 1999 01:30:56 GMT
"Lyal Collins" <[EMAIL PROTECTED]> writes:
> I have yet to see such a simple policy approach address what I call the 30 -
> 1million issue.
> i.e.
> Why should the rules for 30 people doing $1m transactions be different from
> those for 1 million people doing $30 transactions?
>
> The overall business/systemic risks are approxiamently equivalent.
some of the attack points are the same and some are different.
the old style checks with signing limits has been one model proposal
for certificate pki ... build into the certificate language similar to
signing limits. the attack point turned out to be aggregation
... certificates can be used for atomic operations but have very poor
operational characteristics where aggregation can be involved (fraud
where somebody with a $5000 signing limit discovered that they could
do million dollar transactions by writing 200 checks)
for the points that are in common to the different transaction types
(a million $30 transactions or 30 million dollar transactions) need to
have similar integrity levels ... and it does need to be account based
to handle aggregation-like issues.
an AADS signing chip is an attack point for a specific account ... not
for the infrastructure as a whole (for one thing it doesn't have any
system-wide shared secret &/or systemic risk characteristics). the
integrity of any single chip has to be compareable to the benefit
gained from attacking it. A specific AADS signing chip might possible
have parameterized risk management specifying things like the maximum
individual transaction size, the transaction velocity, the maximum
aggregated number of transanctions in some interval and the maximum
aggregated value of transactions in some interval.
the transaction authorization and execution infrastructure has to have
integrity compareable to the aggregation of all possible transactions
it might process ... however any single AADS signing chip only needs
integrity compareable to the transactions that the specific chip might
be used for.
The AADS case has been that the account-based transaction
authorization and execution infrastructure for financial operations
has to exist regardless of any other operational characteristics.
Given that such an account-based infrastructure has to exist, then it
is trivially shown that having CA & certificates as part of that
infrastructure's transactions represents redundant & superfulous
operations and needlessly increases the infrastructure's systemic
risk.
--
--
Anne & Lynn Wheeler | [EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: HD encryption passphrase cracked!
Date: 29 Dec 1999 20:48:39 EST
In article <84dq9o$a5g$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Keith A
Monahan) wrote:
>
>Hey,
>
>NFN NMI L. ([EMAIL PROTECTED]) wrote:
>: "Secure Deletion of Magnetic Media", Peter Gutmann. Good reading. I have the
>: URL somewhere.
>
>It's http://www.uncwil.edu/Ed/INSTRUCT/burt/edn416/secure_del.html here.
>
>: By the way, now that it doesn't matter, what WAS the passphrase? :-D
>
>I did contemplate posting it as most people would probably get a kick
>out of it and would understand why it took so long. However, if someone
>managed to get ahold of the ciphertext say awhile back, they could now
>use the key. Sorry! :)
A 44 word passphrase with 7 punctuation characters? Don't you think that
you went just a bit overboard? Just using "I did contemplate posting it
as most people would probably get a kick out of it" would seem to be
secure enough. No wonder you found it hard to remember!
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Video card reconfiguration
Date: 29 Dec 1999 21:03:15 EST
In article <84dg54$6v8$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Julien Dumesnil)
wrote:
>
>
>> Doesn't seem likely to me.
>>
>> Why not get Motorola's AIM evaluation board, development libraries, etc.
>
>John,
>
>I'm sure I've read this info somewhere (don't remember where tho...)
>
>Anyway the idea is _not_ to use specialised hardware. but to use a board
>that could
>be bought through any computer hardware reseller... And reprogram it to be
>faster than
>any PIII at doing cypher manipulation.
>
>Don't know if you get my drift...
Bad idea. You will be spending half a year by an experienced
programmer to save a couple of hundred dollars in hardware costs.
------------------------------
Date: Wed, 29 Dec 1999 21:44:00 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Secure Delete Not Smart
lordcow77 wrote:
> In article <[EMAIL PROTECTED]>, "John E. Gwyn"
> <[EMAIL PROTECTED]> wrote:
> > Donald Haines wrote:
> > > The only truly secure delete is to remove the platters and to
> > > destroy them.
> > In an emergency, we toss them into a container full of thermite
> > and set it off.
> > - Douglas
>
> Forgive my ignorance, but wouldn't the disks take a long time to be
> damaged by the fire? And if thermite is an explosive, wouldn't one
> still be able to read the data off the fragments?
It's not an explosive, just a very hot fire. It's used for cutting and
welding. The temperatures range from 4000 to 5500 oF.
>
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
> The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Date: Wed, 29 Dec 1999 21:51:13 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Cryptography in Tom Clancy
Eric Lee Green wrote:
> John Savard wrote:
> > But the purpose of a novel is to entertain, so a few technical
> > implausibilities, as long as they help to advance the plot, are not to
> > be concerned about. (In fact, of course, I would expect that the
> > STU-III would not be that "close" to being breakable that even the NSA
> > could do so a decade hence; that would be irresponsible underdesign.)
>
> An aquaintance who was once in the Air Force commented that their encryption
> machines were almost as old as the B-52 bombers that they were flying.
>
> I'm sure those antiques have been retired by now, but the point is that the
> armed forces aren't always using the "latest and greatest", and that it takes
> years between the time new technology is developed, and the time it is
> deployed. It would not surprise me if the NSA was capable of breaking Air
> Force encryption today that was done ten years ago on twenty-year-old
> encrption machines.
A few days ago the Air Force announced that it expects B-52s to be in service
through 2045.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: More idiot "security problems"
Date: Thu, 30 Dec 1999 02:46:24 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote:
> "the original rule" was from Schneier:
>
> >>>>A corollary is that: "Anyone can create an encryption algorithm
that
> >>>>he himself cannot break."
>
> which is specifically restricted to individuals, producing the clear
> implication that groups do not have the same limitation. They do.
That's a statement of what seems to be; it is no
more proven that is the strength of my favorite
cipher. We cannot disprove that some group has
a universal reduction algorithm which efficiently
breaks any complexity-based cipher that is itself
efficient in use. We cannot even put a reliable
upper bound (less than one) on the probability
that such an algorithm is known.
Yet we still hear people reject conventional
ciphers for lack of provable, quantifiable
security, and then propose an alternative with
the same drawback. Given any complexity-based
encryption, no matter how layered and dynamic,
we cannot yet disprove that some attack breaks
it easily, thoroughly and permanently.
And one nit: asserting the rule for individuals
in no way implies, or even suggests, it is false
for groups.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Attacks on a PKI
Date: Thu, 30 Dec 1999 03:12:25 GMT
> >I was looking at the SSL protocol yesterday and read about how
> >the man in the middle attack was foiled by a certificate. And
> >I asked the question of this news group how IE validates a cert
> >that a server issues to the client (IE)? Someone responded and
> >I searched the "internet options" dialog tab and sure enough,
> >there was a long list of CAs. I imagine that IE goes to those
> >web sites and verifies a cert.
>
> You don't understand what a CA is. Certificates don't work anything
> like the way you're imagining. The certificate check is done totally
> inside the browser. The CA can be completely offline. Try surfing
> around www.verisign.com or www.thawte.com and reading some of the
> tutorials at those sites.
Then all you need to do is compromise the IE database.
What good is a database that holds such important
information if it can be compromised to support a
man in the middle attack so easily?
Even if it were encrypted, either the key is stored somewhere or
it is well known and hidden in the binaries. I seriously did not
expect PKI to be so easily compromised by such a design. I thought
for sure that IE would keep itself aware of the latest certs from
the CAs. What if they are revoked? Would IE know? From what you
say, no it would not. Am I correct?
--
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: [EMAIL PROTECTED]
Subject: Re: AES wise?
Date: Thu, 30 Dec 1999 03:10:40 GMT
That most prolific of writers, Anonymous, wrote:
> 1) Given the record of Blowfish having no attacks against the full
> algorithm, why do none of the AES candidates use fully key-dependant
> S-boxes? Is it because it is tough to make an f-function fully
bijective
> that way, or is it just cumbersome to prove protection against
differential
> analysis, or what?
I think it is to avoid needing a RAM controller
in hardware implementations.
> 2) It would seem that creating only one algorithm for ALL purposes
for
> ALL implementations is a little silly. Others posting to this group
have
> asked "why not choose more than one winner." That is not what I am
saying. I
> say that the AES goal is flawed: Why did NIST not just call for two
> algorithms? (One for high security, and one for implementations where
> resources are low.) Even just two versions of the same algorithm?
In many applications, multiple platforms of widely
different capabilities must (en/de)crypt the same
data. Thus we want at least one cipher that is
well-analyzed and efficient across the widest
possible range of environments.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Attacks on a PKI
Date: Thu, 30 Dec 1999 03:14:17 GMT
> Do Netscape and IE require that the certificates be specific to the
> domain name, or does it just require that a certificate be used?
> If not, unless the user checks that the certificate matches
> the domain, a man-in-the-middle could have a certificate of
> his own and masquerade as the remote site by intercepting
> all traffic the user sends.
SSL can take care of this. I am just surprised that it relies
on a database local to IE. That seems like a truly weak link.
--
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: Greg <[EMAIL PROTECTED]>
Subject: Re: SSL And Certificate Verifications
Date: Thu, 30 Dec 1999 03:22:11 GMT
So let's say that I create my own CA, and I issue myself a cert
that is to be given to an IE during a man in the middle attack.
First, I get the cert into the IE's database, then when I pass
it off in place of the server, it is accepted as authentic.
Is it really that simple to hack?
--
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: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: SSL And Certificate Verifications
Date: 30 Dec 1999 03:47:25 GMT
In article <84ei7m$q4m$[EMAIL PROTECTED]>, Greg <[EMAIL PROTECTED]> wrote:
>So let's say that I create my own CA, and I issue myself a cert
>that is to be given to an IE during a man in the middle attack.
>First, I get the cert into the IE's database, then when I pass
>it off in place of the server, it is accepted as authentic.
>
>Is it really that simple to hack?
No.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Attacks on a PKI
Date: 30 Dec 1999 04:00:57 GMT
In article <84ehvr$pqr$[EMAIL PROTECTED]>, Greg <[EMAIL PROTECTED]> wrote:
>Then all you need to do is compromise the IE database. What good is
>a database that holds such important information if it can be
>compromised to support a man in the middle attack so easily?
If you've got enough control over the user's machine to mess with the
browser cert store without the user's permission, you can almost
certainly take over the rest of the machine too, so it's all over
anyway. It really doesn't matter how the cert system works at that
point, and you certainly don't need a MITM attack.
I think I'm going to stop answering your posts now. I suggest you
read some more about how SSL and CA's work instead of making wild
assumptions in your posts. You're flaming without knowing what you're
talking about.
------------------------------
** 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
******************************
