Re: Questions about generating keys (hash firewalls)

[Robert J. Hansen]

Doug Barton wrote:
> It almost sounds from what you're saying above that there actually is an 
> argument for RSA's hash firewall being "better" than DSA[2] here, but if I 
> correctly understood what you said later in the thread, the margin by 
> which it's "better" is so small as to not be worth considering. Is that 
> more or less correct?

I think I was the one who made that argument and said the margin was
ultimately not worth considering, so I hope you'll forgive me answering
this one despite it being addressed to David.

Anyway.  Yeah, I think that's a fair assessment.  Is there a benefit?
Yes.  Does the benefit matter?  Not really.

Or, as David said, if your property is surrounded by a 1000-foot fence,
a 1001-foot fence is not going to be much better.  If the bad guy can
clear a 1000-foot fence, the additional foot probably isn't going to
stop him.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about generating keys (hash firewalls)

[Doug Barton]

On Sat, 25 Aug 2007, Doug Barton wrote:

> The other question I had is about what you said above regarding truncating 
> hashes with DSA2. Am I understanding correctly that even with DSA2 the hash 
> size can be no larger than 160 bits?

*sigh* Never mind this bit, I just re-re-read a later part of the thread 
where you said that it was possible to generate a DSA2 key that can use a 
full 256 bit hash.

I'm still curious about the issue of whether the hash firewall issue makes 
a "significant" difference or not though.

Doug

-- 

If you're never wrong, you're not trying hard enough

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about generating keys (hash firewalls)

[Doug Barton]

On Fri, 24 Aug 2007, David Shaw wrote:

> On Fri, Aug 24, 2007 at 09:06:24PM +0300, Oskar L. wrote:
>
>> Do hash firewalls have any drawbacks (performance decrease, difficult to
>> implement, patent issues etc.)? What's the reason DSA doesn't have one?
>
> I suspect a major reason is the main use of DSA is really DSS - and
> DSS was never intended to be used with any hash other than SHA-1.
>
> It gets a little stickier with DSA2/DSS2 where there are several
> possible hashes.  For example, a 1024/160 DSA key can use SHA1, but
> also SHA224, SHA256, SHA384, or SHA512, by truncating them to 160
> bits.

I've followed this thread with interest, since my only signing key is a 
1024 DSA key, and I'm considering options for what my "next" key should 
be.

It almost sounds from what you're saying above that there actually is an 
argument for RSA's hash firewall being "better" than DSA[2] here, but if I 
correctly understood what you said later in the thread, the margin by 
which it's "better" is so small as to not be worth considering. Is that 
more or less correct?

The other question I had is about what you said above regarding truncating 
hashes with DSA2. Am I understanding correctly that even with DSA2 the 
hash size can be no larger than 160 bits?

Thanks,

Doug (who hopes these questions aren't too dopey)

-- 

If you're never wrong, you're not trying hard enough

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Scott Seidl/Schneider is out of the office.

[SeidlS]

I will be out of the office starting  08/24/2007 and will not return until
08/30/2007.

I will return your message when I get back.

Thanks


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about generating keys

[Robert J. Hansen]

Dan T. wrote:
> This is no real mystery:

Wrong domain.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about generating keys

[Dan T.]

--- "Robert J. Hansen" <[EMAIL PROTECTED]> wrote:


> > > This is not my experience.  I've received spam
addressed to my amateur
> > >  radio call sign (KC0SJE) at a domain that's not
directly associated with
> > >  me.  I don't know how it was discovered, but
for right now I'm leaning
> > >  towards the hypothesis that spammers have made
pacts with the Devil and
> > >  learned dark arts.
> > 
> 
> > Oskar L. wrote:
> >  My first guess would be that you are in one of
> > your friends address
> > book, and your friend has spyware that got it.
> > 
> This is not the case.  No one had it except me.

== Snipped ==

This is no real mystery:

The address kc0sje AT sixdemonbag.org is available on
the MIT key server:



It is also in Google:



Dan



   

Building a website is a piece of cake. Yahoo! Small Business gives you all the 
tools to get online.
http://smallbusiness.yahoo.com/webhosting 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about generating keys

[Robert J. Hansen]

Oskar L. wrote:
> The point of certificates is for you to be able to verify that you 
> are on the site you think you are, and not a fake one.

Yes--which involves trust.  Do you trust the certificate authority?  Do
you trust that the site in question isn't trying to scam you?  Etc., etc.

Trust lies at the root.  Always.

> To say that a site isn't authentic because you don't trust the 
> information on it or the people that run it makes little sense.

If I actively distrust the people who are providing me with information,
that's much more fundamental than actively distrusting the information
itself.  Failing to trust information because I actively distrust the
people involved in its production and conveyance makes a heck of a lot
of sense to me.

And without that fundamental trust, there is no possible authentication.

Trust lies at the root.  Always.

> Is politician X's site authentic because we agree with him/her, but 
> politician Y's is not, because we disagree with him/her?

If you think disagreeing with someone is the same thing as actively
distrusting them, I feel sorry for you.  It is a very poor way to live.

> Mallory can never be unauthentic, only someone pretending to be her 
> can.

Clearly, I've had the misfortune of knowing worse sociopaths than you have.

> Anyone can tell you they are Trevor. If you visit him authentication
>  is easy, you recognize him by his looks, the sound of his voice etc.
>  Crypto makes authentication over the Internet possible.

How do you know he's Trevor?

How do you know he is who he says he is?  How do you know he's not
impersonating someone named Trevor?

How do you know you're not being taken for a ride?

How do you know you can trust yourself?

> "I just do, all right?"
> 
> That's not a good answer. It offers no facts or logical reasoning.

Great.  Prove that you exist.  Offer facts and logical reasoning that
affirms your own existence.  Keep in mind that you can't argue using
facts from existence itself, since that reduces down to an assumption of
a fact not in evidence--that existence exists.

Philosophers have been wrestling with this for a few thousand years,
from Rene Descartes' brain-in-a-jar to Gregory Chaitin's holographic
universe to--I'm blanking on his name, but a philosopher was once asked
to refute solipsism and did so by kicking a rock very hard.  While
hopping around on one foot and cursing, he exclaimed "I refute it thus!"

Epistemological reasoning aside, declarative truth lies at the root of
every piece of inductive logic.  In mathematics, they are called axioms.
Take Euclidean geometry as an example: take the most convoluted
construction in Euclidean geometry and you will reduce it down to the
handful of axioms Euclid declared, such as "parallel lines never intersect".

Why do parallel lines never intersect?  Because Euclid declared they
never intersect.  Declarative truth--an axiom.

By definition, axioms offer neither facts or logical reasoning.  They
simply exist.  "I just do, all right?!" is the root axiom of trust.

> If a company tells you their products are the best, and you ask them
> why, would you be satisfied if they answered "they just are, all 
> right?"

Why do you think that authenticity is universal?

It's not.  You don't get any say over whom I trust or to what degree.
That has some real significance for signatures.

Alice: You can trust this message from Charlene.  She signed it.
Bob:   Err--why should I trust her signature?
Alice: Because I verified her key.  So the message has a sig, the sig
   came from a key, the key has sigs on it, each sig came from a
   key, one of those keys is mine.  Perfect chain of trust.  There,
   see?  Charlene's message is authentic.
Bob:   ... who are you, and why do I care if your signature is on
   Charlene's key?
Alice: ...
Bob:   ...
Alice: ...
Bob:   Right.  Well, have a nice day!

Trust is a very personal decision.  If I choose to be satisfied by the
company's declaration, that's my business.  If I choose not to be
satisfied, that's my business.

> "I believe X to be authentic, because I note it has Y which vouches 
> for it."
> 
> That's logical reasoning, but leaves the question of why you trust Y
>  unanswered.

Yes.  Inductive proofs are like that.  You reason by inductive steps
until you reach a basis case.  It's rather a lot like my instructions
for how to climb down a ladder:

1.  If you're on the ground, stop.
2.  Otherwise, move down a rung and climb down from there.

The fact that inductive cases are not basis cases--and likewise, the
fact that basis cases tend to be axiomatic--is so obvious that I'm
having great trouble seeing what you're getting at.

> -This thing is authentic, because I have verified it myself.

You're begging the question.

Why is it authentic?  Because you've verified it yourself.  Why does
that make it authentic?  Because you trust yourself.  Why do you trust
yourself?  Because you just _do_, all right?

> My ability to look at th

Re: Questions about generating keys

[John Clizbe]

Oskar L. wrote:
>> Ultimately, you trust _someone_.  Which is precisely the point I made:
>> trust underlies everything.  Without that fundamental trust, there's no
>> point talking about authenticity.
> 
> If that someone is yourself, do you still call it trust?

Well, I can't speak to what you call it. But...

  PGP calls it implicit trust.

  GnuPG calls it ultimate trust.

Or as Robert would say, "I trust that key because it is mine. I created it.
Ergo, I trust it because I say that I trust it."



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about generating keys

[John Clizbe]

Oskar L. wrote:
> Robert J. Hansen wrote:
>> why trust is a necessary precondition for authentication.  Without it,
>> everything falls apart.
> 
> You can trust Trevor, but this trust is useless if you have no way of
> authenticating that Trevor really is Trevor.
> 
> Trust is not needed for authentication. You can authenticate a lot of
> things just by looking at them, your friends for example.

You're not trusting your own recollection, your memory, that they are indeed
your friends? If a stroke or other accident wipes away those memories, they will
no longer be recognized as your friends; the memory, hence, the trust has been
removed.

You're back to trusting because you say so.

Say what you want, it's all authentication is built on trust.



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about generating keys

[Oskar L.]

> Ultimately, you trust _someone_.  Which is precisely the point I made:
> trust underlies everything.  Without that fundamental trust, there's no
> point talking about authenticity.

If that someone is yourself, do you still call it trust?

Some things about myself I only trust, such as my memory about certain
things.

Other things I am completely sure of, and don't call trust. That I won't
all of a sudden hit myself in the face for no reason, for example.

My ability to look at the fingerprint on a paper, and compare it to the on
on the screen, is something I'm completely sure I'm capable of doing
correctly, so therefore I call a key I have verified authentic, not
trusted. Maybe you call it trusted, and we are just arguing about the
meaning of words?

Oskar


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about generating keys (hash firewalls)

[Oskar L.]

Allen Schultz wrote:
> Is there a comprehensive list of hashes used in encryption that can
> help me choose which is the best to use?

I'm sure there is, but such a list would not do you much good. The
application you use probably only supports a few. Some are old and
insecure, and should not be used. I suggest you check what hashes your
application supports, then read about them on Wikipedia. Here's a few:

http://en.wikipedia.org/wiki/SHA1
http://en.wikipedia.org/wiki/RIPEMD160
http://en.wikipedia.org/wiki/WHIRLPOOL

Oskar

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about generating keys

[Oskar L.]

> If I had good reason to believe Google was up to something nefarious,
> there is nothing in heaven or earth that would cause me to say "yes,
> that site is authentic."

The point of certificates is for you to be able to verify that you are on
the site you think you are, and not a fake one. If you go to somesite.com,
and the certificate is ok, then the site is _authentic_. If the
certificate is not ok, then someone might have messed with your DNS
settings or hosts file, making somesite.com go to the wrong IP, and the
site you get is then fake.

To say that a site isn't authentic because you don't trust the information
on it or the people that run it makes little sense. Does McDonald's not
have an authentic site because we don't believe them when they say their
food is healthy? Is politician X's site authentic because we agree with
him/her, but politician Y's is not, because we disagree with him/her?

Mallory might be a liar who you don't trust, but that does not mean that
it's impossible for anyone to authenticate that Mallory really is Mallory.
Mallory can never be unauthentic, only someone pretending to be her can.

> Trust is the ultimate dealbreaker.  Always has been, always will be.

Yes you can trust your friend Trevor, and yes weather you trust him or not
is the deal breaker. But you also need to authenticate him by some means.
Anyone can tell you they are Trevor. If you visit him authentication is
easy, you recognize him by his looks, the sound of his voice etc. Crypto
makes authentication over the Internet possible.

> Authentication in a nutshell, can be summed up in a single sentence.
> Unfortunately, you get two choices in how to finish it.
>
>
>
> I believe this thing to be authentic, because...
>
>   * I just do, all right?
>   * I note it has something authentic which vouches
> for it.

"I just do, all right?"

That's not a good answer. It offers no facts or logical reasoning. If a
company tells you their products are the best, and you ask them why, would
you be satisfied if they answered "they just are, all right?"

"I believe X to be authentic, because I note it has Y which vouches for it."

That's logical reasoning, but leaves the question of why you trust Y
unanswered.

> Choose one of the two statements.  If you choose the latter, then
> continue the chain.

I would rather have:

-This thing is authentic, because I have verified it myself.

-I trust this thing, because someone I trust and have verified claims it
to be.

> Why is the signature authentic?  Because the key which made the
> signature is authentic.

Yes, that's logical.

> Why is the key which made the signature authentic?  Because a signature
> on that key is authentic.

No then it's only trusted. The signature on the key is authentic, yes, and
the public key you use to verify the signature is also authentic. But the
information, someone claiming that another a key is authentic, is only
trusted. You can't verify that your friend isn't lying to you by using any
kind of crypto. This is the weak link in the chain which brings everything
down to the level of trust.

The key would be authentic if you had verified it yourself.

> Why is the key which made the signature authentic?  Because that's
> John's own key.
>
> Why does that make the key authentic?  Because he just does, all right?

It doesn't. Verifying the fingerprint would make it authentic.

> Follow an authentication chain
> far enough and you will always, inevitably, reach trust, some level
> where the answer is "because I just do, all right?"

If there are other people besides yourself involved in the chain, and they
are providing information which you do not verify, only trust, then yes,
trust is the weakest point. But that does not mean that everything in the
chain is only trusted. Somewhere in the chain we could have 5+5=10, and we
do not need to trust this, we can be 100% sure of it.

> why trust is a necessary precondition for authentication.  Without it,
> everything falls apart.

You can trust Trevor, but this trust is useless if you have no way of
authenticating that Trevor really is Trevor.

Trust is not needed for authentication. You can authenticate a lot of
things just by looking at them, your friends for example.

Oskar


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about generating keys

[Robert J. Hansen]

Sven Radde wrote:
> 1) If it means "the site contents are created by a particular firm", 
> it is not necessary to trust that firm in any way to deem the site 
> "authentic".

How do you know it's created by a particular firm?  Who told you?  How
did you find out?  What's the provenance of your information?  How was
it conveyed to you?

Ultimately, you trust _someone_.  Which is precisely the point I made:
trust underlies everything.  Without that fundamental trust, there's no
point talking about authenticity.

Each person gets to decide for themselves what are the fundamental
questions of trust, as well as answers to those questions.  These are
the holiest of the holies in a security policy; these are heartbeats
that animate every policy and mechanism.  Where does the trust lie, and
what implications does this trust--or lack thereof--have on the rest of
the system?

> It is the same with "trusting" keys in GnuPG. Trust, in this case, 
> only means that the key belongs to a particular person (by inductive
>  reasoning as you explained very nicely).

No disagreement, but a terminology note: the terms "keytrust" and
"ownertrust" appear to be on their way out, replaced by "validity" and
"trust".  Speaking for myself, I like this change; it seems to reduce
confusion in newcomers.

> The person itself could be a total a**h**e but that would not prevent
> [key validity].

This was pointed out in my post.  At some point you say "I trust them
because I trust them."  If you choose to trust someone despite knowing
they are fundamentally untrustworthy, that's your choice, and I don't
have any say in it.

As for me, I choose not to trust people I consider fundamentally
untrustworthy.  Nobody else has a say in that, either.

> If I know that said a**h**e, despite of his other attitudes, always
> takes utmost care in verifying other people's keys, I can assign an 
> appropriate ownertrust.

This is not about being nice or being a jerk.

Authenticity != trust != niceness.  While authenticity is dependent upon
trust, niceness appears orthogonal to them both.

> As another point, think of codesigning-certificates. Just because, 
> e.g., an ActiveX control is signed, it does not mean that it is safe,

Correct.  On the other hand, if it's signed by someone you trust
(there's that word again), then there's no reason not to use it.  After
all, its provenance is vouched by the signature... the signature is
vouched by the key... the key is vouched by some trust relationship...
and ultimately you reach the "I trust it because I say so and it's my
choice" point.

>  or whatever property one would like to claim about its 
> contents/functions. It only means that it was created by the 
> certificate owner and not manipulated by a third party.

The signature only says the certificate owner vouches for the provenance
of the code, not necessarily that the author vouches for it.  Unless you
have the special case where the signer is the same as the author.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about generating keys (hash firewalls)

[Robert J. Hansen]

Allen Schultz wrote:
> Is there a comprehensive list of hashes used in encryption that can
> help me choose which is the best to use?

If all you want is to provide a very high level of authentication for
your messages, just stick with the defaults and you'll do just fine.

Seriously.  GnuPG is specifically designed so that the defaults are
sensible for the overwhelming majority of users.

There is no "best" hash.  My usual metaphor is that arguments over the
"best" hash function, the "best" key, the "best" encryption algorithm,
etc., are about as meaningful as debating whether Godzilla or
Mechagodzilla is more effective at flattening Tokyo.  No matter which
one you choose, Tokyo gets flattened.



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about generating keys (hash firewalls)

[Allen Schultz]

Is there a comprehensive list of hashes used in encryption that can
help me choose which is the best to use?

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users