surveillance, Re: long-term GPG signing key
Ben Laurie wrote: Perhaps this is time to remind people of Security Against Compelled Disclosure: http://www.apache-ssl.org/disclosure.pdf. Thanks. Survelillance technology is now almost 6 years ahead of April, 1999, when the cited Report to the Director General for Research of the European Parliament was issued. Today, surveillance is not just a political problem or a concern for someone involved in illegal activities, or just about breaking my own privacy. Surveillance has become an ubiquitious threat to the right to privacy and duty of confidence to others whom I have the legal or moral obligation to protect, dramatically increasing the probability of disclosure by eliminating the need to know block usually applied to reduce disclosure risk. Untrustworthy individuals exist and are hard to detect in any organization, including federal and law enforcement agencies and at any government level. The need to know policy, which would be the #1 barrier to prevent more individuals to be exposed to the critical information, directly reducing the probability of disclosure, is silently destroyed by surveillance. Thinking about IT security needs in the XXI century, the solution of using encryption and document control to prevent surveillance and secret-disclosure would seem to impose itself. Despite the apparent simplicity and widespread availability of public-key cryptography, PGP and X.509 S/MIME, less than 5% of all email is encrypted. Banks won't even consider using encryption for sending out monthly statements and notices. It's not just the mounting problem with email fraud schemes such as spoofing and phishing. Banks discovered that not even their own employees were willing to use encryption. The real security question of the XXI century is easy-of-use -- that the security solution will actually be used takes precedence over any potential benefits. In this context, the subject of email security is being discussed at http://email-security.net/ -- please take a look at the Blog and Papers sections. Contributions are welcome. A comparison of current email technologies is presented at http://email-security.net/papers/pki-pgp-ibe.htm Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: long-term GPG signing key
Travis H. wrote: I must admit, I just had a duh moment. Why the heck am I expiring encryption keys each year? Anyone who records the email can crack it even if the key is invalid by then. All it really does is crudely limit the quantity of data sent under that key, which is little to none anyway. So that you can't be legally required to produce the private key (which you destroyed, right?). Perhaps this is time to remind people of Security Against Compelled Disclosure: http://www.apache-ssl.org/disclosure.pdf. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: long-term GPG signing key
| Even though triple-DES is still considered to have avoided that
| trap, its relatively small block size means you can now put the
| entire decrypt table on a dvd (or somesuch, I forget the maths).
|
|
| This would need 8 x 2^{64} bytes of storage which is approximately
| 2,000,000,000 DVD's (~ 4 x 2^{32} bytes on each).
|
| Probably, you are referring to the fact that during encryption of a
| whole DVD, say, in CBC mode two blocks are likely to be the same
| since there are an order of 2^{32} x 2^{32} pairs.
|
| Thanks for the correction, yes, so obviously I
| muffed that one. I saw it mentioned on this list
| about a year ago, but didn't pay enough attention
| to recall the precise difficulty that the small
| block size of 8 bytes now has.
|
| The difficulty with 3DES's small blocksize is the 2^32 block limit when
| using CBC -- you start getting collisions, allowing the attacker to
| start building up a code book. The amount of data is quite within
| reach at gigabit speeds, and gigabit Ethernet is all but standard
| equipment on new computers. Mandatory arithmetic: 2^32 bytes
But the collisions are after 2^32 *blocks*, not *bytes*. So the number to
start with is 2^35 bytes.
| is 2^38
So this correspondingly is 2^41.
| bits, or ~275 * 10^9. At 10^9 bits/sec, that's less than 5 minutes.
And this is about 10^10/40 minutes.
| Even at 100M bps -- and that speed *is* standard today -- it's less
| than an hour's worth of transmission. The conclusion is that if you're
8 hours.
| encrypting a LAN,
Realistically, rekeying every half an hour is probably acceptable. In fact,
even if an attacker built up a large fraction of a codebook, there is no
known way to leverage that into the actual key. So you could rekey using
some fixed procedure, breaking the codebook attack without requiring any
changes to the underlying protocols (i.e., no extra data to transfer).
Something like running the key through a round of SHA should do the trick.
If it's agreed that this is done after the 2^30 block is sent/received, on
a 1GB network you're doing this every 20 minutes, with essentially no chance
of a practical codebook attack.
(Not that replacing 3-DES with AES isn't a good idea anyway - but if you
have
a fielded system, this may be the most practical alternative.)
| you need AES or you need to rekey fairly often.
Perhaps I'm being a bit fuzzy this morning, but wouldn't using counter mode
avoid the problem? Now the collisions are known to be exactly 2^64 blocks
apart, regardless of the initial value for the counter. Even at
10GB/second,
that will take some time to become a problem. (Of course, that *would*
require redoing the protocol, at which point using AES might be more
reasonable.)
-- Jerry
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: long-term GPG signing key
Alexander Klimov wrote:
On Wed, 11 Jan 2006, Ian G wrote:
Even though triple-DES is still considered to have avoided that trap,
its relatively small block size means you can now put the entire
decrypt table on a dvd (or somesuch, I forget the maths).
This would need 8 x 2^{64} bytes of storage which is approximately
2,000,000,000 DVD's (~ 4 x 2^{32} bytes on each).
Probably, you are referring to the fact that during encryption of
a whole DVD, say, in CBC mode two blocks are likely to be the
same since there are an order of 2^{32} x 2^{32} pairs.
I've actually seen something like this happen in real life.
As you know, RSA has been running a series of 'Secret Key
Challenges', wherein we ask people to try to brute-force
messages encrypted with RC5 at various keystrengths. There is
a cash prize for the person turning in the correct response.
The messages are encrypted in CBC mode with 32 bit blocks.
The start of the message has a known plaintext
Most of the recent challenges have been won by distributed.net.
While they were working on the 64 bit challenge, I received an
email saying that a proposed solution had been found, and was asked
to check it. (We set up the challenges in such a way that the
correct keys are unknown, even to us).
The supplied key correctly decrypted the first block, but the
rest were gibberish. After scratching our heads, we realized
that d.net had found a collision.
It was almost a year later they found the correct key, for the
$10,000 prize. They immediately started on the 72 bit challenge.
(I'm not holding my breath).
Peter Trei
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: long-term GPG signing key
On Sat, Jan 14, 2006 at 12:30:25PM -0700, Anne Lynn Wheeler wrote: Guus Sliepen wrote: By default, GPG creates a signing key and an encryption key. The signing key is used both for signing other keys (including self-signing your own keys), and for signing documents (like emails). However, it is possible to split the signing key into a master key that you only use to sign other keys, and a key dedicated to signing documents. You can revoke the latter key and create a new one whenever you want, the master key is still valid. Also, when people sign your key, they sign your master key, not the subkeys. The signatures you accumulated will also still be valid. You can also keep the master key safely tucked away on an old laptop that you keep in a safe, and only export the subkeys to your workstation. That way the master key is very safe. as in previous post ... i assert that fundamental digital signature verification is an authentication operation http://www.garlic.com/~lynn/aadsm22.htm#5 long-term GPG signing keys and doesn't (by itself) carry with it characteristics of human signature, read, understood, approves, agrees, and/or authorizes. It depends on how it is used. For example, when I sent this email, I typed in the passphrase of my PGP key, authorising GnuPG to create a signature for this email. This comes very close to human signing. I read, understood, approve etc. with the contents of this email. If assymetric cryptography is used to automatically sign a credit card transaction without the user having to do more than click a button, then I agree that in that situation, the digital signature is not the same as a human signature. [...] it is when you start equating private keys with certification and truth characteristics that you move into a completely different risk and threat domain. I don't equate private keys with that. I do equate signatures made with those keys with that. the other foray into embellishing private keys and digital signatures with human signature type characteristics was the non-repudiation activity. however, it is now commoningly accepted that to embellish digital signatures with non-repudiation attributes requires a whole lot of additional business processes ... not the simple operation of generating an authentication digital signature. [...] the corollary is that digitally signed certificates and private keys embellished with certification and truth characteristics become less and less meaningful. That is probably true, but in the mean time Travis still wants to know how to create a PGP key with the properties he wishes for. -- Met vriendelijke groet / with kind regards, Guus Sliepen [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: long-term GPG signing key
Guus Sliepen wrote: It depends on how it is used. For example, when I sent this email, I typed in the passphrase of my PGP key, authorising GnuPG to create a signature for this email. This comes very close to human signing. I read, understood, approve etc. with the contents of this email. If assymetric cryptography is used to automatically sign a credit card transaction without the user having to do more than click a button, then I agree that in that situation, the digital signature is not the same as a human signature. but as in some of the PKI forays into non-repudiation and human signatures ... there was no way for a relying party to determine the difference ... and in the previous thread of digital signature dual-use vulnerability, this can open up fraud. at one point, some were assuming if there was a digital certificate with the non-repudiation flag set, then the digital signature indicated human signature (read, understood, agrees, approves, and/or authorizes). however, nothing in various PKI protocols providing for proving which digital certificate was actually appended to a particular digital signature (appending a non-repudiation digital certificate might imply the creation of some obligation associated with a digital signature used as a human signature; however there was no protocol provisions for establishing which form of digital signature was actually intended and/or which digital certificate was actually appended to any particular operaion). the dual-use vulnerability has an environment where servers nominally transmit random data for signing (one of the possible countermeasures for replay attack) and the person generates a digital signature on the random data w/o having looked at the data (assuming purely authentication operation). the other party has actually substituted some sort of valid text in place of the valid data and then asserts that the person has performed the digital signature implying a human signature (read, understood, agrees, approves, and/or authorizes) as opposed to implying pure authentication operation. the crook may attempt to further substantiate the fraudulent claim by producing a digital certificate (for the corresponding public key) with the non-repudiation bit set (and PKI protocols lack provisions for differentiating which, of possible several, digital certificates might actually have been attached). the possible dual-use for digital signatures then may lead to enormous ambiguity since the basic technology only provides for authentication ... and that w/o significant additional business processes it is difficult to differentiate digital signatures used for purely authentication purposes and the grossly embellished purposes associated with human signatures. any embellishing of digital signatures for human signature purposes, in turn creates significant additional risk than straight-forward authentication. a basic issue isn't what you intended when you caused a digital signature to be created ... but what can any relying-party reasonably expect that you intended ... and what can the relying-party reasonably rely on. then if there is any possible ambiguity as to what you may have intended when a digital signature was created, can an attacker use the existence of such ambiguity to perpetrate fraud (aka dual-use vulnerability). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: long-term GPG signing key
Travis H. wrote: Why the heck am I expiring encryption keys each year? Anyone who records the email can crack it even if the key is invalid by then. All it really does is crudely limit the quantity of data sent under that key, which is little to none anyway. If your threat model includes attacks on the system(s) you use to decrypt messages, or rubber hose/subpoena key-cracking, expiring *and wiping* confidentiality keys limits the time during which the keys can be compromised using those methods. -- Blogzilla:http://dooom.blogspot.com/ Say no to ID cards! http://www.pledgebank.com/refuse2 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: long-term GPG signing key
I must admit, I just had a duh moment. Why the heck am I expiring encryption keys each year? Anyone who records the email can crack it even if the key is invalid by then. All it really does is crudely limit the quantity of data sent under that key, which is little to none anyway. *bonks forehead* -- http://www.lightconsulting.com/~travis/ Vast emptiness, nothing sacred. -- Bodhidharma -- GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: long-term GPG signing key
On Wed, 11 Jan 2006, Ian G wrote:
Even though triple-DES is still considered to have avoided that
trap, its relatively small block size means you can now put the
entire decrypt table on a dvd (or somesuch, I forget the maths).
This would need 8 x 2^{64} bytes of storage which is approximately
2,000,000,000 DVD's (~ 4 x 2^{32} bytes on each).
Probably, you are referring to the fact that during encryption of a
whole DVD, say, in CBC mode two blocks are likely to be the same
since there are an order of 2^{32} x 2^{32} pairs.
--
Regards,
ASK
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: long-term GPG signing key
On Wednesday 11 January 2006 08:04, Ian G wrote: [...] I don't think EC is available for OpenPGP although GPG may have some experimental product in it? RFC2440 has 9.1. Public Key Algorithms has ID 18 as Reserved for Elliptic Curve followed by the statement Implementations MAY implement any other algorithm. [...] -- Rob Skedgell [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: long-term GPG signing key
On Tue, Jan 10, 2006 at 03:28:49AM -0600, Travis H. wrote: I'd like to make a long-term key for signing communication keys using GPG and I'm wondering what the current recommendation is for such. I remember a problem with Elgamal signing keys and I'm under the impression that the 1024 bit strength provided by p in the DSA is not sufficiently strong when compared to my encryption keys, which are typically at least 4096-bit D/H, which I typically use for a year. The whole reason I'm using a signing key is that I have numerous older keys which have now expired and so the signatures on them are worthless. I don't attend many keysigning parties so it's hard to make the system work without collecting signatures over a long period on some very high strength key. Also, I'd like to use the signing key as a kind of identity, not tied to any particular email address, and only used to sign communication keys, which *are* tied to a email address and have shorter expiration times. Does anyone have any suggestions on how to do this, or suggestions to the effect that I should be doing something else? By default, GPG creates a signing key and an encryption key. The signing key is used both for signing other keys (including self-signing your own keys), and for signing documents (like emails). However, it is possible to split the signing key into a master key that you only use to sign other keys, and a key dedicated to signing documents. You can revoke the latter key and create a new one whenever you want, the master key is still valid. Also, when people sign your key, they sign your master key, not the subkeys. The signatures you accumulated will also still be valid. You can also keep the master key safely tucked away on an old laptop that you keep in a safe, and only export the subkeys to your workstation. That way the master key is very safe. About keys being tied to email addresses (uids): you can create a uid with just your name, no email address, and if you like a comment with your birthday or passport number in it. Let people sign that uid. -- Met vriendelijke groet / with kind regards, Guus Sliepen [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: long-term GPG signing key
Alexander Klimov wrote:
On Wed, 11 Jan 2006, Ian G wrote:
Even though triple-DES is still considered to have avoided that
trap, its relatively small block size means you can now put the
entire decrypt table on a dvd (or somesuch, I forget the maths).
This would need 8 x 2^{64} bytes of storage which is approximately
2,000,000,000 DVD's (~ 4 x 2^{32} bytes on each).
Probably, you are referring to the fact that during encryption of a
whole DVD, say, in CBC mode two blocks are likely to be the same
since there are an order of 2^{32} x 2^{32} pairs.
Thanks for the correction, yes, so obviously I
muffed that one. I saw it mentioned on this list
about a year ago, but didn't pay enough attention
to recall the precise difficulty that the small
block size of 8 bytes now has.
A few calculations here - even blueray disks won't
help me out.
iang
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: long-term GPG signing key
Amir Herzberg wrote: Ian G wrote: Travis H. wrote: I'd like to make a long-term key for signing communication keys using GPG and I'm wondering what the current recommendation is for such. I remember a problem with Elgamal signing keys and I'm under the impression that the 1024 bit strength provided by p in the DSA is not sufficiently strong when compared to my encryption keys, which are typically at least 4096-bit D/H, which I typically use for a year. 1. Signing keys face a different set of non-crypto threats than to encryption keys. Agreed. In practice, the attack envelope is much smaller, less likely. Huh? It depends on the application. Many applications care only (or mostly) on authentication, e.g. secure DNS (or CA). Or secure payment protocols (not based on sending `secrets` such as credit card numbers...). Well, yes, depends on the application of course! With this particular application - signing people's keys for WoT - that's generally true. If I was to crack your signing key for example, then wander around impersonating you, this is unlikely to do anything useful except confuse people a lot until you all figure it out. If we limit our discussion to actual extent and popular protocols, it is easier to see. Take for example this *extreme* case of the CA application. If I was to publish Verisign's private key on usenet, what difference would that make? Other than a lot of red faces, not as much as one would think; they would simply roll another key, then re-sign everyone's certs and post them out with a free year for the nuisance factor. Then a CERT advisory would tell every merchant to roll over their certs, and browsers would ship new roots. (Actually it's probably worse than that. We stand at the cusp of SSL attacks, 450 seen last year, so this would spur a bunch of forged cert attacks. Compare this to a couple of years back when someone noticed that IE had a cert bug in it, and nobody noticed. And nobody ever bothered to attack it.) But that's the *extreme* case, more or less like Microsoft faces every month. For the regular case of say Amazon's private key, well, Amazon would have a lot of nuisance to deal with, but in practice it would just be in up-tick in normal phishing against them for a few months. Various random posts: Netcraft - 450 phishing cases using SSL / HTTPS certs https://www.financialcryptography.com/mt/archives/000624.html RSA comes clean: MITM on the rise, Hardware Tokens don't cut it, Certificate Model to be Replaced! https://www.financialcryptography.com/mt/archives/000633.html GP4.3 - Growth and Fraud - Case #3 - Phishing https://www.financialcryptography.com/mt/archives/000609.html 3. The RSA patent expired, which means that RSA no longer has everyone over a barrel. For various reasons, many projects are drifting back to RSA for signing and for encryption. Yes, but depending on how many years you need, the length of key can become substantial/a concern. In which case, you may consider some of the EC signatures or other short signatures. Be careful regarding the hashing, though. I don't think EC is available for OpenPGP although GPG may have some experimental product in it? On the whole - another complete generalisation - open projects tend to shy away from EC as there is no clear patent situation, and putting all the work in only to discover some claim later on is not effective use of time. Our Cryptix project to do EC in Java (Paulo in Brazil) stalled when he discovered that the so-called unencumbered set was actually quite slow... iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: long-term GPG signing key
There are a number of differences in key management priorities between (communication) signature and encryption keys. For encryption keys: - you want short lived keys - you should wipe the keys after at first opportunity - for archiving you should re-encrypt with storage keys - you can't detect or prove an encryption key is compromised as the attacker will just be decrypting documents For signature keys: - you want longer lived keys (or two tier keys, one for ceritfying that is kept offline, and one for signing communications that is offline) - in fact many applications dont even want signatures they want authentication (convince the recipient of author and integrity, but be non-transferable) - with signature keys if they are compromised and the compromised key used, there is risk (to the attacker) that the recipient or others can detect and prove this. I do agree tho that the relative value of encryption vs signature depends on teh application. Adam On Wed, Jan 11, 2006 at 09:04:07AM -0500, Perry E. Metzger wrote: Ian G [EMAIL PROTECTED] writes: Travis H. wrote: I'd like to make a long-term key for signing communication keys using GPG and I'm wondering what the current recommendation is for such. I remember a problem with Elgamal signing keys and I'm under the impression that the 1024 bit strength provided by p in the DSA is not sufficiently strong when compared to my encryption keys, which are typically at least 4096-bit D/H, which I typically use for a year. 1. Signing keys face a different set of non-crypto threats than to encryption keys. In practice, the attack envelope is much smaller, less likely. I call bull. You have no idea what his usage pattern is like, and you have no idea what the consequences for him of a forged signature key might be. It is therefore unreasonable -- indeed, unprofessional -- to make such claims off the cuff. -- Perry E. Metzger [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: long-term GPG signing key
Travis H. wrote: On 1/10/06, Ian G [EMAIL PROTECTED] wrote: 2. DSA has a problem, it relies on a 160 bit hash, which is for most purposes the SHA-1 hash. Upgrading the crypto to cope with current hash circumstances is not worthwhile; we currently are waiting on NIST to lead review in hashes so as to craft a new generation. What's wrong with SHA-256 and SHA-512? http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf I agree though that hashes (I hate the term, hashing has little to do with creating OWFs) are not as advanced as block cipher design, and 160 bits seems rather small, but surely SHA-256 would be better than throwing one's hands up, claiming it's unsolvable, and sticking with SHA-1, right? Well, it's a pragmatic situation: * all SHA algorithms are under a cloud * anything 160 bits or less is under a dark-ish cloud * the bigger ones won't break, but maybe the engineering will all change anyway * DSA has to be upgraded anyway * what's wrong with RSA in this role? * where's the threat to the DSA algorithm given that the attack is the birthday attack? * where's the threat to any extent usage of DSA (within its application profile)? Pragmatically, wait and see is a good choice here, IMO, but others disagree. If the problem is size, the answer is there. If the problem is structural, a temporary answer is there. DSA is fixed to a 160 bit hash (or is it DSS?). So, it's possible to do RIPEM or a chopped off version of SHA-256. The question is, what does that gain you? Not that much, and probably not as much as the pain of rolling out a new digsig algorithm. Using two structurally different hashes seems like a grand idea for collision restistance, but bad for one-wayness. One-wayness seems to matter for message encryption, but doesn't seem to matter for signing public keys - or am I missing something? Well, using two different MDs to cover one failing is a plausible idea - but at a logical and cryptographic level, all you are doing is inventing your own hash algorithm, constructed from some prior work. So, we can look at for example cipher chaining like triple-DES. There are strange artifacts such as groups where non-obvious things come in and trip you up. Even though triple-DES is still considered to have avoided that trap, its relatively small block size means you can now put the entire decrypt table on a dvd (or somesuch, I forget the maths). So in general, it's not a good idea to just invent your own algorithms; if you could do better so easily, so could the professional cryptographers, and they would have by now. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: long-term GPG signing key
Perry E. Metzger wrote:
Ian G [EMAIL PROTECTED] writes:
Travis H. wrote:
I'd like to make a long-term key for signing communication keys using
GPG and I'm wondering what the current recommendation is for such. I
remember a problem with Elgamal signing keys and I'm under the
impression that the 1024 bit strength provided by p in the DSA is not
sufficiently strong when compared to my encryption keys, which are
typically at least 4096-bit D/H, which I typically use for a year.
1. Signing keys face a different set of
non-crypto threats than to encryption
keys. In practice, the attack envelope
is much smaller, less likely.
I call bull.
You have no idea what his usage pattern is like, and you have no idea
what the consequences for him of a forged signature key might be. It
is therefore unreasonable -- indeed, unprofessional -- to make such
claims off the cuff.
You seem to have missed the next sentance:
Unless you have
particular circumstances, it's not
as important to have massive strength in
signing keys as it is in encryption keys.
As he asked what the current recommendation
is it seems reasonable to assume the general
case, not the particular, and invite him to
elaborate if so needed. Etc etc.
Errata - if you (Travis) are using 4096-bit D/H
as your encryption keys, you might want something
a bit beefier for signing keys. Check out
the key length calculator:
http://www.keylength.com/
and click on NIST 2005 Recommendations and
also ECRYPT 2005 Report for comparison.
iang
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: long-term GPG signing key
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
Re: long-term GPG signing key
Travis H. wrote: I'd like to make a long-term key for signing communication keys using GPG and I'm wondering what the current recommendation is for such. I remember a problem with Elgamal signing keys and I'm under the impression that the 1024 bit strength provided by p in the DSA is not sufficiently strong when compared to my encryption keys, which are typically at least 4096-bit D/H, which I typically use for a year. 1. Signing keys face a different set of non-crypto threats than to encryption keys. In practice, the attack envelope is much smaller, less likely. Unless you have particular circumstances, it's not as important to have massive strength in signing keys as it is in encryption keys. 2. DSA has a problem, it relies on a 160 bit hash, which is for most purposes the SHA-1 hash. Upgrading the crypto to cope with current hash circumstances is not worthwhile; we currently are waiting on NIST to lead review in hashes so as to craft a new generation. Only after that is it possible to start on a new DSA. So any replacement / fix for DSA is years away, IMO. The OpenPGP group has wrestled with this and more or less decided to defer it. 3. The RSA patent expired, which means that RSA no longer has everyone over a barrel. For various reasons, many projects are drifting back to RSA for signing and for encryption. Does anyone have any suggestions on how to do this, or suggestions to the effect that I should be doing something else? If you want something stronger, then I'd suggest you just use a big RSA key for signing. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
