Cryptography-Digest Digest #809, Volume #10 Wed, 29 Dec 99 19:13:01 EST
Contents:
letter-frequency software ("r.e.s.")
Re: Grounds for Optimism (Mok-Kong Shen)
Re: Employing digits of pi (CLSV)
Re: Secure Delete Not Smart (lordcow77)
Re: letter-frequency software (James Pate Williams, Jr.)
Re: SSL And Certificate Verifications (Greg)
Re: Secure Delete Not Smart (Mike Andrews)
Re: Attacks on a PKI (Larry Kilgallen)
Re: Secure Delete Not Smart (Steve K)
Re: Attacks on a PKI (Timothy M. Metzinger)
Re: Attacks on a PKI (Timothy M. Metzinger)
MORE BIJECTIVE COMPRESSION POSSIBILITES (SCOTT19U.ZIP_GUY)
Re: Diffie-Hellman ("Michael Scott")
Re: SSL And Certificate Verifications (Paul Rubin)
Re: Attacks on a PKI (Mickey McInnis)
----------------------------------------------------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: letter-frequency software
Date: Wed, 29 Dec 1999 14:21:44 -0800
At http://www.und.nodak.edu/org/crypto/crypto/stattools/
there is C source code for a program (letcount.c), to do
some simple letter-freqency anaylsis, but, unfortunately,
I don't have access to a C-compiler. Does anyone know
where an executable version of this might be found?
(preferrably for win98, but even DOS will do ;)
Thanks for any feedback.
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Grounds for Optimism
Date: Wed, 29 Dec 1999 23:45:22 +0100
John Savard wrote:
>
> Hence, my call for doing more in ciphers than we can justify as
> necessary. Naturally, care must be taken - and cryptanalysts know how
> this is to be done - that any added complexity is not so flawed as to
> vitiate the strength of the cipher to which it is added.
I believe that some added security, whether one 'really' needs that
-- a question one also 'really' never knows for sure --, does have
some psychological benefits at least. Besides, to predict (or even
to know) when some major breakthroughs in crypto analysis methods
or techniques take place seem to me to be at least as hard as
predicting natural catastrophes. Engineers use to employ ample factors
of safety to cater for unknowns, but sometimes they got greatly
surprised nonetheless, as history shows. As to 'added complexity' I
suppose that the term (though clear in the present context) should
not be (elsewhere) unintentionally interpreted by some to mean that
crypt algorithms should be designed in 'complicated' (difficult to
understand and without clear rationales, as not seldom happend) ways,
for simplicity and easy comprehensibility should reign all genuinely
good programs, whether crypto or not. Your point of big keys
implies in my opinion that algorithms should preferrably be designed
to have at least the key length as parameter, i.e. user choosable.
Finally I believe one clean and simplest way to obtain 'added
complexity' is via multiple encipherment with two algorithms that
are sufficiently different from each other, which 'practically'
guarantees that there can be increase but no reduction of strength.
(Hopefully this doesn't re-kindles the old discussion of whether
there should be multiple AES-winners!)
M. K. Shen
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: Employing digits of pi
Date: Wed, 29 Dec 1999 22:44:21 +0000
Mok-Kong Shen wrote:
> By the way, could you please give a definition of your 'side channel
> attack'? I rather have doubt that I have catched that from the
> context of the paragraph above.
This is a link to a paper that describes the principles
and practice.
http://www.counterpane.com/side_channel.html
Regards,
CLSV
------------------------------
From: lordcow77 <[EMAIL PROTECTED]>
Subject: Re: Secure Delete Not Smart
Date: Wed, 29 Dec 1999 14:36:42 -0800
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?
* 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: [EMAIL PROTECTED] (James Pate Williams, Jr.)
Subject: Re: letter-frequency software
Date: Wed, 29 Dec 1999 22:56:58 GMT
On Wed, 29 Dec 1999 14:21:44 -0800, "r.e.s." <[EMAIL PROTECTED]>
wrote:
>At http://www.und.nodak.edu/org/crypto/crypto/stattools/
>there is C source code for a program (letcount.c), to do
>some simple letter-freqency anaylsis, but, unfortunately,
>I don't have access to a C-compiler. Does anyone know
>where an executable version of this might be found?
>(preferrably for win98, but even DOS will do ;)
>
>Thanks for any feedback.
>
>--
>r.e.s.
>[EMAIL PROTECTED]
>
>
Write your own Java program. Java is free and you don't have to trust
someone else's executable that could house a nasty virus.
==Pate Williams==
[EMAIL PROTECTED]
http://www.mindspring.com/~pate
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: SSL And Certificate Verifications
Date: Wed, 29 Dec 1999 22:38:18 GMT
> >I am reading up on SSL and came across the certificate verification
> >process. It says that the certificate is validated by several steps.
> >At one point, the issuer is verified, according to this document, by
> >an unspecified mechanism. So how does IE or Netscape verify an
> >issuer that it finds in a server's certificate?
>
> A list of trusted issuers is built into the browsers as distributed
> by Microsoft and Netscape. You can see the list in in Netscape 4.x by
> clicking the lock icon and selecting "signers" in the left hand menu
> of the dialog that pops up. In IE, select View->Internet Options-
>Content
> ->Authorities.
So given this list, how does IE, for example, verify the issuer of a
certificate that it receives from a server? Does it go to that CA and
query? If so, what is to stop a man in the middle from emulating every
CA and produce positive results for all forged certificates?
>
> >Also, does the process of verifying the issuer dependent upon the
> >level of security that the browser is setup to allow?
>
> Kind of sort of but not really. There are a bunch of different
protocols
> possible and some browsers support more of them than others.
>
--
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] (Mike Andrews)
Subject: Re: Secure Delete Not Smart
Date: Wed, 29 Dec 1999 22:55:53 GMT
lordcow77 <[EMAIL PROTECTED]> 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?
Thermite burns at about 3000 degrees Celsius - yes, _violently_
exothermic - and gives off enough energy per unit weight to
melt at least a few unit-weights of disk material.
Really, all that's needed is to raise it above the Curie temperature,
so that all the magnetic domains lose their orientations. They
randomize when they cool down again, if the material is sintact.
But melting is decidedly irreversible, and so is the easier
route.
--
Mike Andrews
[EMAIL PROTECTED]
Tired old sysadmin since 1964
------------------------------
From: [EMAIL PROTECTED] (Larry Kilgallen)
Subject: Re: Attacks on a PKI
Reply-To: [EMAIL PROTECTED]
Date: Wed, 29 Dec 1999 22:50:32 GMT
In article <84dum1$nag$[EMAIL PROTECTED]>, David A Molnar
<[EMAIL PROTECTED]> writes:
> Now if you and the PKI have different notions of what "good enough" means
> -- say, you think "good enough" includes being "not too weak" and the PKI
> just thinks "good enough" means "we looked at his Vermont driver's
> license" -- then you will be in trouble. Maybe it is your own fault
> for not studying PKI statements carefully, but that will be hard to
> take after someone repudiates a key and the PKI says it's not their
> problem.
>
> Put another way, how do you know that you and the PKI have the same notion
> of an "authentic" key? and how weird does your application need to be
> before you should worry that the PKI doesn't think about keys the
> way you do?
Written contracts and legal agreements, backed up by the opportunity
to sue for breach of contract. If the agreements you have signed do
not give you sufficient comfort, then you have signed the wrong agreement.
Larry Kilgallen
------------------------------
From: [EMAIL PROTECTED] (Steve K)
Subject: Re: Secure Delete Not Smart
Date: Wed, 29 Dec 1999 23:09:20 GMT
On Tue, 28 Dec 1999 23:59:47 -0600, "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
And detonate the primacord necktie. Gotta securely delete the
operator, just to be safe.
;o))
Steve K
---Continuing freedom of speech brought to you by---
http://www.eff.org/ http://www.epic.org/
http://www.cdt.org/
PGP key 0x5D016218
All others have been revoked.
------------------------------
From: [EMAIL PROTECTED] (Timothy M. Metzinger)
Subject: Re: Attacks on a PKI
Date: 29 Dec 1999 23:21:41 GMT
>> 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: [EMAIL PROTECTED] (Timothy M. Metzinger)
Subject: Re: Attacks on a PKI
Date: 29 Dec 1999 23:21:41 GMT
In article <84dum1$nag$[EMAIL PROTECTED]>, David A Molnar
<[EMAIL PROTECTED]> writes:
>Put another way, how do you know that you and the PKI have the same notion
>of an "authentic" key? and how weird does your application need to be
>before you should worry that the PKI doesn't think about keys the
>way you do?
You read the CA policy and Certificate Practices Statement for that particular
PKI.
It should spell out:
How keys are issued (how the individual "proves" his identity to the issuer)
How keys are revoked and how to verify them (or "Where's the CRL?")
What the keys issued may be used for (some PKI's will limit the liability of a
signature based on policies - see my earlier post)
How the CA Key and the individual keys are required to be protected.
The useful life of a key pair.
And a lot more. There aren't many "industrial strength" PKI's yet in the US,
because nobody is yet very comfortable with a lot of the legal and privacy
issues. There are some good models for PKI operation being developed.
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: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: MORE BIJECTIVE COMPRESSION POSSIBILITES
Date: Thu, 30 Dec 1999 00:38:04 GMT
I have a new page on my site http://members.xoom.com/ecil/compres6.htm
it is a set of files adaptive and static huffman programs that convert from
files with limited symbol sets to files of a Normalized Fintiely Odd File
type. This can be used to convert a set of X symbols to a file of Y symbols
in a bijective way. With or with out real compression being done.
the ziped file is http://members.xoom.com/ecil/ah2af.zip
the files from byte types to FOF types is at
http://members.xoom.com/ecil/fin2int.zip
Have a Happy New Year
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction of the
truth."
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: Diffie-Hellman
Date: Wed, 29 Dec 1999 23:45:54 -0000
Daniel Roethlisberger <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Trying to understand Diffie-Hellman in order to implement it, I stumbled
> across the following sentence in Applied Cryptography: "... agree on a
large
> prime, n and g, such that g is primitive mod n". <snip>
Primitive means that g^i mod n generates all the integers between 1 and n-1.
So for example 2 is primitive with respect to 11 as 2^1 mod 11, 2^2 mod 11
etc generate the numbers 2,4,8,5,10,9,7,3,6,1 in that order, which are the
numbers 1 to 10 mixed up. This immediately suggests the cryptographic
potential, as y=g^x mod n is in this case acting as a random S-Box - but an
S-Box with a simple mathematical structure. Note in particular (as Diffie
and Hellman did) that g^(ij) mod n = g^(ji) mod n. Note that the smallest i
such that g^i mod n = 1, is referred to as the "order" of g with respect to
n. So the order of 2 is 10.
Anyway to be explicit ensure that n is a "safe prime", that is n is prime
and so is (n-1)/2. Then set g=3 or g=4. The advice to use a primitive g is
out-dated, its actually best that g be a generator of the prime order
sub-group of order (n-1)/2.
Mike Scott
> Regards,
> Dan
>
>
>
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: SSL And Certificate Verifications
Date: 29 Dec 1999 23:49:18 GMT
In article <84e1uk$el0$[EMAIL PROTECTED]>, Greg <[EMAIL PROTECTED]> wrote:
>So given this list, how does IE, for example, verify the issuer of a
>certificate that it receives from a server? Does it go to that CA and
>query? If so, what is to stop a man in the middle from emulating every
>CA and produce positive results for all forged certificates?
The public keys for the issuers are BUILT INTO THE BROWSER. If you
buy a brand new PC with w98 and MSIE preinstalled, for example, the
list is already there. And when you download a new copy of IE, the CA
list is part of the auto-installation package. If someone slips you a
bogus IE installation kit, they can mess with the CA list before you
install the browser. There is a separate system called Authenticode
for preventing that, but not everyone uses it.
------------------------------
From: [EMAIL PROTECTED] (Mickey McInnis)
Subject: Re: Attacks on a PKI
Date: 29 Dec 1999 23:44:13 GMT
Reply-To: [EMAIL PROTECTED]
In article <84duuv$m0r$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul Rubin) writes:
|> In article <84damo$u5j$[EMAIL PROTECTED]>, Greg <[EMAIL PROTECTED]> wrote:
|> >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.
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.
In this scenario, the user is vulnerable unless he clicks on the
security info for a page and verifies that it's "correct".
Even if the browser requires matching domain name/certificates, a
man-in-the-middle could forge a redirect of a web page request to a
mirror site owned by the attacker with a matching certificate. In this
case, the user is vulnerable unless he notices that the URL has changed.
This wouldn't be that easy to notice, since lots of sites have multiple
servers or even use external service providers. Think about it, if you
were at xyz.com web site and the "secure" order page took you to
"mrmserve.com/xyzorders/...", would you notice. Would you then check
the certificate? If the certificate was owned by "MRM order processing
services", would you be suspicious? How would you know that this "mrm"
stuff isn't a domain/certificate owned by the man-in-the-middle?
How about it? Are these attacks feasible with a man-in-the-middle
attack?
--
Mickey McInnis - [EMAIL PROTECTED]
--
All opinions expressed are my own opinions, not my company's opinions.
------------------------------
** 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
******************************
