Lots of questions

[Henry Hertz Hobbit]

On 27 Oct 2005, Christoph Anton Mitterer wrote:
<SNIP>
</SNIP>

Rather than quoting what you have, I will just go through what
your points and make comments.  If I don't comment, I leave it
to OTHERS to make the comments or you to hash it out alone.  For
the others, reply to his questions, not my comments (unless I am
totally wrong).

Whew, you asked a lot of questions.

  I   GnuPG specific questions
===============================
1. Differences between 1.4.x & 1.9.x - OTHERS

2. symmetric + asymmetric - > total asymmetric
I leave this for OTHERS, but generally speaking, from a
historical perspective, the reason it was encrypted with
symmetric, and only the session key was done assymetrically was
because it would have taken FOREVER to do it with the just
asymmetric.  If you finally are able to do it all with
asymmetric, don't we have a problem that now the algorithms
themselves (and / or bit sizes) are susceptible to attack?  What
I am carefully leading you towards is that the ever increasing
power of CPUs changes the game.  What we can crack today wasn't
even feasible ten years ago.  The game changes as CPU power
increases.

3. encrypt & sign - look at the souce code (I may be wrong here)

4. --gnupg totally compliant with OpenPGP / RFC 2440?  OTHERS.
However, according to the man pages, strictly speaking no. For
that you use --openpgp or --rfc2440 which for now are
equivalent.

5. The best random number source (for generating new keys) are
engines that are not purely deterministic.  For now those are
ones that roll your mouse movements, key strokes and other stuff
into the works for generating the numbers.  Most versions of
Linux are good because they do this, but older Unix Systems
(Solaris, AIX, HPUX) can be bad which is why you use the Entropy
Gathering Daemon or some other entropy adding method with them.

6. E, S, CS, & CSA meanings - OTHERS.

7.  4096 bit limit - well first, there are some algorithms that
have hard limits built into them.  Even if they don't, a 4096
bit key right now (29 Oct 2004) is HUGE.  I can remember us
thrashing out being able to use more than 96 bits 15+ years ago
with the NSA.  When you generate a 4096 bit key (and use it), be
prepared for some awfully long times for things to be done.  I
have a 2+ GHz Athlon chip and it still took 4-5 minutes to
generate the keys (I played Mahjongg tiles while it was working
away on it).

8. Diff between 32 bit OS and 64 bit OS in creating keys -
OTHERS.

9. --set-notation - see the man page.  Since it seems entirely
clear to me I don't understand what you are missing.  They are
primarily to store key values or other items when signing if
that is what you are after.  If it isn't, be more precise why
you are asking it.  Are you saying that it doesn't work?  I
have never used it so I don't know.


II   OpenPGP specific questions
=================================
1.  Why can't you use RSA and ElGamal?  You can.  ElGamal is
primarily used for encryption, NOT signing.  For GnuPG, DSA is
the primary signing method.  RSA has been included since version
1.0.3.  IDEA is not included because there is a patent that will
not expire until 2007.

2.  Is ElGamal the same as Diffie/Hellman?  No, and yes.  It is
not EXACTLY the same.  It is just based on the Diffie-Hellman
key agreement:

        http://en.wikipedia.org/wiki/Elgamal

For the rest of it you are now starting to sound like that
professor in Back to School who had just one question in
multiple parts.  I leave it to OTHERS to answer these questions.
I am getting a head ache just looking at all of them.

3.  Why would you use a signing subkey for self-signatures?  I am
afraid I live in a minimalist universe and see no reason, but
OTHERS may have a very good reason.

4.  How are my secondary keys connected to the primary?  Good
queston!  I am waiting for OTHERS to make it intelligible.  In
reality, the UID (I prefer the term KEY ID) and the fingerprint
are bound tightly together and one does not exist in absence of
the other.

5.  I am not quite sure what you are saying here.  Signing a
message is not exactly the same thing as signing somebody else's
key.  You seem to be mixing the two things together.  I like to
think that when you sign somebody else's key, in a sense they
got married.  The signer key and the signee key are now bound
together with a certain level of trust, and it is announced to
the world.  That is what the Web Of Trust (WOT) is all about.
When you sign a message you use that other agreement (the WOT)
to determine how much you can trust the message.  I was debating
on whether or not to write an entire missive on this to the
group.  The ad-hoc rules for the WOT need to be replaced with an
extremely formalized methodology, but before you put the rules
in place you need to hammer out what you are verifying.  OTHERS
- don't reply to my statements here, reply to his original
questions.

6.  How are you going to handle things if there is NO default UID?
I think some of the OTHERS need to explain where they are going
here. Even I am getting confused, e.g (portion of --list-keys):

pub   1024D/985A444B 2002-06-03
uid                  Tomasz Kojm <tkojm at clamav.net>
uid                  Tomasz Kojm <tk at lodz.tpnet.pl>
uid                  Tomasz Kojm <zolw at konarski.edu.pl>
sub   1280g/08C827F9 2002-06-03

In case you are wondering, he is one of the top developers at
ClamAV.  Now, will the default UID please stand up?  What I am
trying to say is that as it is listed here, there is NO default
UID, just a sequence of them tied to key 985A444, and a sub key
08C827F9. They are all bound together.  In essence, they are a
single entity with ties to other keys based on the signing of
his key.

7.  Of COURSE there is a difference between self-signatures to
UIDs and signatures to other UIDs.  Unless your name is DX, and
you have a split personality where there is the bad DX, the good
DX, and the objective DX, nobody knows you better than yourself.
This is not hypothetical - I really knew somebody like this with
bad DX saying they should rob the bank, good DX saying that was
wrong, and objective DX saying they shouldn't do it because they
would get caught and be put in jail.  All three voices came from
the same physical body, but the sounds of the voices and the
personalities were entirely different!  With that caveat, who
knows you better than yourself?  The signature to your own ID
has the highest level of trust.

8.  What is stored in a UID-signature?  OTHERS.  Go look in the
source code.  Concerning the "it get's worse", if you add a new
UID, in effect your key has changed, just as it has changed if
somebody has signed your key.  I think all of this wasn't
thought out well enough and is too complicated. However let's
ask a semantic question.  Going back to number 6 here
(hypothetical), you knew Tomasz Kojm at school with the email
address <zolw at konarski.edu.pl>.  You signed his key. Then he got
a new address <tk at lodz.tpnet.pl>.  Do you still trust him, and
more to the point the new address?  Since he is saying he is the
same guy you knew at school, you fire off a message to his
school address and ask if he has added this new email address to
the key.  He says that he has.  The only thing that has changed
is an extra UID.  Your trust is exactly the same as it was
before, BUT this should be noted by downloading (importing) his
key again and asserting that it is the same entity (in this case
person) by signing it again.  What you are signing are HIS / HER
records (or maybe an organization but the way it is now you seem
to need a PERSON for signing), and if they change, it is your
responsibility to re-sign the changes.

9.  Signatures of other people shouldn't be invalidated unless
you alter your UIDs (add / remove), or add / delete subkeys.
OTHERS may disagree with me.  I could care less how you change
your default ciphers, compression, etc.  I might think you are
foolish doing it if it makes it impossible for you to
communicate with others.  Signing policy is more a function of
the possessor of the key, than of the key itself.

10. OTHERS.  If the encryption engines change to the point that
your secret keys can't be read you have to start over with a new
set of keys.  Interoperability with older PGP software is
legendary in not working.

11.  Options for losing signatures?  I can't think of any
technical reasons.  OTHERS?

12.  When creating more than one encryption subkey ...  There
are as many reasons for this as there are people and their
needs.  For example, do you need the same bit size for emailing
to somebody else a message that you don't care whether it is
broken two weeks later as that document you want to squirrel
away for years and years?  That is just ONE reason for doing it.
Personally, I don't have that type of need.

13.  I don't understand the question.  What do you  mean when
you are asking: "why you would want to create multiple sub keys
and have each and every one of them signed."  I think that is
what you are saying. Look at this example:

pub   1024D/AE053BE0 2004-03-10 [expires: 2014-03-08]
uid                  RADVIS (Per Tunedal Casual) <pt at radvis.nu>
uid                  Info RADVIS <info at radvis.nu>
uid                  Jobb RADVIS <jobb at radvis.nu>
sub   1024D/DB6C057F 2004-03-10 [expires: 2006-03-10]
sub   2048g/983AB16A 2005-02-01 [expires: 2006-04-07]

Are you asking is there a reason for signing sub key  DB6C057F
but not signing 983AB16A?  That doesn't even make sense to me.
Do OTHERS know what he is asking here?  I don't.

III   Algorithm Specific Questions
===================================
1.  Asymmetric Algorithms:
Any asymmetric algorithms do not depend solely on GnuPG.  They
need to be part of the OpenPGP standard.  Your PGP cousins will
need to be able to decrypt your messages, and you need to
decrypt there messages.  Nuff said.  And before you dump on PGP,
I can see that businesses really may want to go with PGP over
GnuPG.  It isn't that their staff are dumb.  THEY ARE SWAMPED
and out-sourcing the configuration of encryption may be money
very well spent.  Before the advent of spies and worms, a lot of
people didn't use to believe that encryption had general purpose
use.  Well, it does have general purpose use now.

2.  Symmetric Algorithms:
When it comes to Symmetric algorithms, I would NEVER order them
in terms of preference.  For example you put CAST5 next to the
last in order of preference, yet it is the default for GnuPG.
Is that because you have the idea that using something other
than the default is a good idea, or an inherent dislike of
CAST5?  Personally, I like TWOFISH:

        http://www.schneier.com/twofish.html

It is unpatented, the source code is uncopyrighted, and it was
one of the five AES finalists.  I don't have a strong religious
BIAS here.  Now what if TWOFISH isn't in PGP and I communincate
with somebody using PGP?  Back to CAST5...or what ever they can
handle.  But if you are saying what you want to use for your own
personal files, then use the strongest one you think will last
as long as your need for the file you just encrypted.

3.  Hashing Algorithms:
Do not make the assumption that it is just the number of bits
that makes the difference here.  You have to be able to
inter-operate with others using PGP.  Let's say you pick SHA512,
and PGP cousins don't have it (or even somebody using an older
version of GnuPG).  The message will be unreadable by the
recipient.  Be careful what you you pick.  If you get a clear
text message back saying "Duh, what did you say?" you will know
you picked the wrong thing.  In other words, there is a
usability factor here, and you can be sitting there safe and
sound and unable to communicate with others!  What good does
that do?

4.  Compression Algorithms:
Nuts.  I should leave it at that.  Generally speaking, the best
compression to worst is in the order you have given, but I have
seen cases where it doesn't turn out that way.  Files like PDF,
EXE, JPEG and others like them benefit very little from
compression. Why don't we throw in the proprietary Lev-Zimpel
"compress" program from 'nix boxes from years ago?  Now having
said all that drivel, the default to look at the recipient's
key, use their preference, or if they don't have a preference to
use ZIP sounds fine with me.  Almost everybody has ZIP, and it
is NOT a security question (unless you want them to be totally
unable to uncompress it in which case I wonder why you sent the
message to them in the first place).

 IV     How to create my new key the best way?
==============================================
That is totally up to you.  I do need to add one statement.
bzip2 doesn't have compression levels per-se.  Yeah they are
there, but the faster doesn't make it go all that much faster,
nor does the best make it any better because that is the
default.  I would just take the default unless you want it to go
faster.  And then it doesn't go faster.  But bzip2 is a wonderful
compression algorithm for mainly ASCII text files.

HHH
-- 
Key Name:  "Henry Hertz Hobbit" <hhhobbit at securemecca.net>
pub   1024D/E1FA6C62 2005-04-11 [expires: 2006-04-11]
Key fingerprint = ACA0 B65B E20A 552E DFE2 EE1D 75B9 D818 E1FA 6C62