long-term GPG signing key

[Anne & Lynn Wheeler]

Perry E. Metzger wrote:
> Even in totally ordinary circumstances it is important to have very
> strong signing keys. Your comments were insupportable.

there is a somewhat separate issue having to do with security
proportional to risk. minor old posting:
http://www.garlic.com/~lynn/2001h.html#61

the security acronym  PAIN

P ... privacy (or sometimes CAIN and conficentiality)
A ... authentication
I ... integrity
N ... non-repudiation

part of the problem is that sometimes confusion between digital
signatures and human signatures (implying read, understood, agrees,
approves, and/or authorizes).

the technology is asymmetric keys .... involving a pair of keys, what
one key encodes, the other key decodes (differentiates from symmetric
key encryption where the same key is used for encryption and decryption).

there is a business process commonly referred to as public key where one
key of a asymmetric key pair is identified as public and made available.
the other key is identified as private, kept confidential and never
divulged.

there is a business process called digital signatures where a hash of
some message or document is computed and then encoded. the
message/document is sent off with the appended digital signature. the
recipient recomputes the hash of the message/document and decodes the
digital signature with the corresponding public key. if the two hashes
compare, then the recipient (or relying party) can assume:

1) the message/document hasn't changed since transmission
2) the message/document has been authenticated as originating from the
entity associated with the public key.

the amount of risk is associated with the risk of attack on the
corresponding message/document.

say the digital signature operation is used for authenticating x9.59
transactions
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

that happen to be credit card transactions where the account owner has a
credit limit of $1000, all transactions are online against the account,
the account public key can be deactivated when there appears to be fraud
and to the consumer the frauulent transactions can be reversed (leaving
the consumer with a maximum $50 exposure).

the existing infrastructure has no real authentication operation except
for attempting to maintain the account number as a shared secret (which
implies that the account number ... rather than any public key  ... has
to be deactivated & replaced when there has been compromise):
http://www.garlic.com/~lynn/subpubkey.html#secret
some postings on account number skimming/havesting
http://www.garlic.com/~lynn/subpubkey.html#harvest
some postings on fraud & vulnerabilities
http://www.garlic.com/~lynn/subpubkey.html#fraud

compared to some of the other payment card operations that specified
public key authentication ... x9.59 allowed for

1) digital signature authenticated transactions
2) account number used in authenticated transactions could not be
skimmed and used in non-authenticated transactions (which some of the
other specifications allowed) ... basically countermeasure to form of
replay attacks and countermeasure for having to treat account number as
shared-secret.

the basic issue in both (digital signature) signing keys and encryption
keys is what is the risk from a compromise and based on that risk you
can determine the level security required.

another consideration is the overall infrastructures. for many of the
online e-commerce operations ... an ECC 163-bit signing key probably has
a lot higher security strength than the rest of the infrastructure used
to protect the signing key and/or the environment where the digital
signature is applied. from an attackers standpoint that means that it is
probably cheaper/easier to attack the infrastructure to capture the
signing key ... than to try a brute-force attack on the signing key (and
all of these other attacks are applicable regardless of the strength of
the signing key). there may also be attacks on other parts of the
infrastructure ... getting the financial institution to register a new
public key (belonging to the attacker) or getting a certification
authority to issue a new certificate with the attacker's public key in
the name of the victim. some of these other operations may be currently
weak because the claim is that they aren't currently the weakest link in
overall infrastructure.

there may be other trade-offs. it is possible to get reasonably priced
14443 contactless tokens that can do ecc 163-bit digital signing in
subsecond time that may be desirable in various POS or transit turnstyle
operations. going to larger key sizes may exceed both the power
requirement and the elapsed time requirement (in contact token operatin
you can someimes trade-off peak power draw against onger elapsed time).
The case can be made in some scenarios ... that the longest possible
keylength be chosen if the power and elapsed time requirements aren't a
major factor. However, there can be environments where power and elapsed
time requirements may justify choosing a shorter keylength (within the
context of the overall environment)

one of the things that payment card infrastructures have the ability to
do is a real time risk evaluation on a per transaction basis and pass
judgement on a wide variety of factors which might include ... key
length, whether there is a certifified token protecting the signing key
and what is the evaluated integrity of that token, what kind of terminal
and merchant is used for the digital signing environment, the physical
location of the signing, past consumer transaction history, past
terminal transaction history, etc. one might imagine financial
institution having different minimum token and key length requirements
for different kinds of accounts and/or different kinds of transactions
(based on factors like overall risk and the relative security strength
in which such tokens and signing keys operate).

you might some authorities setting the requirements don't understand the
overall risk and infrastructure issues ... they can always go for the
maximum available for everything ... even if some of the specified
requirements don't make any sense in a particular overall
infrastructurt. the other may be that the infrastructure has no means of
differentiating and authorizing at different levels of risk ... so that
the requirements have to mandate the maximum strength for all
components, always assuming the worst case risk.

there may be a lot higher risk with a (digital signature) singing public
key gets confused with human signatures ... which then may carry with it
the implicattion of a human read, understood, agrees, approves, and/or
autherirzes the contents of what is signed, the risk exposure might also
be greater is if the overall infrastructure is an offline environment
that is totally dependent on digital certificates and PKI operation as
opposed to a real-time, online environment that can take into account a
lot larger numgber of factors (including aggregation of past transactions).

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com