Re: Questions about generating keys (hash firewalls)
Oskar L. schrieb: No, in my example I used two, not one messages (pictures) and created permutations of both, and then compared both groups of hashes against each other. This appears to be somewhere in the middle between a birthday attack and a preimage attack. It looks like a preimage attack on a large set of preimages. Thinking it in the terms of the classical birthday paradoxon would mean to put men and women in a room and check all couples of both sexes for a matching birthday. I am not sure how many, but it definitely needs more people than checking for the same birthday within the whole group. NOT having a hash firewall would reduce the complexity of that attack by a constant factor: You can try all available hash functions to find the collision. This makes a difference in practice only if you can do the hash calculations in parallel (it doesn't really help you to try both SHA-1 and RIPEMD-160, if you could do two SHA-1 calculations in the same time). Thinking this in the classical setting again, it would mean to associate more than one date to each person, besides the birthdate (say, birthdate of boyfriend/girlfriend, etc). This appears to reduce the amount of needed persons in proportion to the number of dates that you associate to each (to keep the same number of dates/hashes available to compare). Given the complexities of the task of finding collisions in cryptography and the number of available hash functions, this reduction does not appear to be very significant. It makes mainly sense if you can actually substitute a weak hash function. cu, Sven ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
Hi! Robert J. Hansen schrieb: Ok, so RSA isn't always significantly faster, as I thought it was. I had read somewhere that it was, (probably on this list) and my own testing with my 4GB backup files showed RSA to be notably faster. I second Robert here. With 4GB of data, the hashing / symmetric encryption takes so long that it is almost totally irrelevant whether you use RSA/DSA/ElGamal. The amount of time for the asymmetric encryption/signing is constant and does not depend on the size of the data. About the only scenario where you would be seriously concerned with asymmetric processing time would be a rapid exchange of very small data packets such as in an instant-messaging session. However, reducing keysize is far more effective here than changing algorithms (according to my experiences with Miranda's GnuPG plugin). - RSA has a hash firewall Yes, but I am unconvinced that this is something an average user needs to be concerned about. (I'm concerned about it, but I freely admit to being paranoid.) I am paranoid, too. Could someone therefore please explain to me what a hash firewall actually is (possibly off-list)? I don't seem to get much info from Google (only hash values from firewall applications... ;-). cu, Sven ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
Hi! Robert J. Hansen schrieb: Think of it this way. Let's say you don't trust Google for some reason. Then you go to https://mail.google.com, and verify that the SSL certificate is correct, so you can be sure your not on a phishing site. Would you now claim that the site isn't authentic, just because you don't trust Google? Darn right I wouldn't. 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. Trust is the ultimate dealbreaker. Always has been, always will be. I think, it is is undefined what it means / should mean that a site is authentic here. 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. 2) If it means that the site content is harmless or the owner treats personal data well or something like that, trust in the owner would be required (in addition to trust in the ownership as such, as defined in 1). 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). The person itself could be a total a**h**e but that would not prevent trust in the key. It would not even prevent the GnuPG concept of ownertrust. 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. There can also be some people that I really, really trust personally but that are totally clueless about the correct verification procedures when signing other people's GnuPG keys. In fact, I know some. So, despite that I trust them, I did not assign any ownertrust to their GnuPG keys (it's not that they would sign many keys anyway...). As another point, think of codesigning-certificates. Just because, e.g., an ActiveX control is signed, it does not mean that it is safe, 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. Summarizingly, we must note that GnuPG, SSL certificates or cryptography as a whole can only help with point 1) mentioned above. Everything beyond proof of ownership/creation is more of a social issue that cannot be solved by crypto. However, it is impossible to do reasoning about the contents themselves, if the ownership isn't established first. cu, Sven ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys (hash firewalls)
On Sun, 26 Aug 2007, Robert J. Hansen wrote: 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. Of course, I appreciate the response. 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. Ok, got it, thanks. 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)
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 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)
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
Re: Questions about generating keys (hash firewalls)
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
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
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 (hash firewalls)
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
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
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. 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
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 the fingerprint on a paper, and
Re: Questions about generating keys
--- 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: http://pgpkeys.mit.edu:11371/pks/lookup?op=vindexsearch=0x5B8709EB It is also in Google: http://www.google.com/search?hl=enq=KC0SJEbtnG=Google+Search 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 wrote: The latest versions of PGP support them. I've got the most up-to-date version of PGP. In fact, it doesn't support them _yet_. The signs are there that they're _almost_ supported - in other words, if you try to add a DSA2 signing subkey the combo boxes have 1536, 2048, and 3072 bit-length options, but when you hit the 'OK' button, you get the message 'Signing key size must be between 1024 and 1024 bits'. A representative from PGP Corporation confirmed (and I quote) that PGP is still prepared to jump to the new DSS standard once it is finalized. Nigel ++ | Give a man a fish and he will eat for a day. Teach him how | | to fish, and he will sit in a boat drink beer all day. | ++ ___ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
On Fri, Aug 24, 2007 at 09:33:59AM +0100, [EMAIL PROTECTED] wrote: Robert J. Hansen wrote: The latest versions of PGP support them. I've got the most up-to-date version of PGP. In fact, it doesn't support them _yet_. The signs are there that they're _almost_ supported - in other words, if you try to add a DSA2 signing subkey the combo boxes have 1536, 2048, and 3072 bit-length options, but when you hit the 'OK' button, you get the message 'Signing key size must be between 1024 and 1024 bits'. A representative from PGP Corporation confirmed (and I quote) that PGP is still prepared to jump to the new DSS standard once it is finalized. Thanks for checking this. Can you tell me what happens if you import a (GPG created) DSA2 key into PGP? Is PGP then able to verify a DSA2 signature created with GPG? It's reasonably common with this sort of thing to enable reading a new feature before enabling writing it. It's the whole be-liberal-in-what-you-accept thing. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys (hash firewalls)
On Fri, 24 Aug 2007 20:06, [EMAIL PROTECTED] said: Do hash firewalls have any drawbacks (performance decrease, difficult to implement, patent issues etc.)? What's the reason DSA doesn't have one? DSA ist the signature algorithm used with DSS, the Digital Signature Standard. DSS requires the use of DSA along with SHA-1 as the hash algorithms. Similar provisions have been setup for DSA1 i.e. the combination of certain key sizes with certain hash algorithms. Thus there is no need for the hash firewall. OpenPGP OTOH allows to use any suitable hash algorithms with DSA. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys (hash firewalls)
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. David ___ 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. wrote: So if we start with Bob, we need to have 253 more people, to be able to make 253 different pairs of which Bob is part of. We need 22 more people. In a room of 23 people, there are C(23, 2) different pairs, or 253. You should probably refresh your knowledge of combinatorics before talking about the birthday paradox. ___ 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 wrote: In a room of 23 people, there are C(23, 2) different pairs, or 253. D'oh. This will teach me to read things quickly. Oskar was specifically saying pairs of which Bob was a part, not total pairs in the room. (gets out the brown paper bag) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
Message: 5 Date: Fri, 24 Aug 2007 08:58:29 -0400 David Shaw wrote: Thanks for checking this. Can you tell me what happens if you import a (GPG created) DSA2 key into PGP? Is PGP then able to verify a DSA2 signature created with GPG? No problem. PGP Desktop accepts the GPG-created DSA2 key quite happily, and verifies the DSA2 signature made in GPG on a separate key. If I import the secret part of the GPG-created DSA2 key PGP will also let me sign keys with it in PGP. hmm... so PGP _does_ support DSA2 really... (but still won't create DSA2 keys) It's reasonably common with this sort of thing to enable reading a new feature before enabling writing it. It's the whole be-liberal-in-what-you-accept thing. Right you are. And I should have known better than to doubt Mr Hansen. ___ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html ___ 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. wrote: calculators designed to show very large numbers can show the result. Now I compare all the hashes from one picture to all the hashes from the other. Doing a birthday attack is highly nontrivial. E.g., to do a birthday attack on SHA256 requires a minimum, a _minimum_, of over 10**17 joules to be liberated as heat. That's about as much as you'd get from an entire full-out strategic nuclear exchange between the US and Russia. You're talking global climate change at that point, along with potential mass extinction of humanity. It's not pretty. Do hash firewalls have any drawbacks (performance decrease, difficult to implement, patent issues etc.)? What's the reason DSA doesn't have one? Historical reasons. Nobody ever thought DSA would be used with anything other than SHA-1, so if there's only one approved hash function, there's no need for a hash firewall. DSS explicitly requires SHA-1 as a hash. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
Nigel Brown wrote: Right you are. And I should have known better than to doubt Mr Hansen. In fact, I was wrong--I said PGP supported creating DSA2 keys, which apparently it doesn't. I foolishly thought that just because I'd seen PGP support using DSA2 keys, that it meant PGP supported creating DSA2 keys. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
Robert J. Hansen 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. My first guess would be that you are in one of your friends address book, and your friend has spyware that got it. If I know that one sort of antispam measure is going to reduce the spam I receive 100-fold over the reduction produced by another antispam measure... and the 100-fold measure takes the same amount of resources as the other one... then why should I ever use the second measure? If the amount of resources are so small that even combined they are insignificant, then why not use both? Everyone who gets sent spam isn't on one single list, which all the spammers use. Spammers get their addresses in different ways, so different spammers will have different lists. Lists are valuable, you can make money by selling a list of working addresses, so they are not likely freely shared between spammers. The fewer lists you are on, the less spam you will be sent. It's not an all or nothing deal. Just because you won't be able to be totally free from spam, is that a good reason to carelessly leave your address all over the Internet? I get a 100-fold reduction from X amount of time and labor, or a 101-fold reduction from a 2X amount of time and labor. This is really simple to me; I'm going to take the 100-fold reduction and spend the extra X time goofing off, or visiting my nephews, or grabbing lunch with my sister, or doing thesis research, or... Yes, it's logical to use the measure(s) that gives the best results for your amount of time and effort. It's also logical to use all of the measures that gives you or you contacts no inconvenience at all. User IDs do not provide any authentication, okay, that much is true. If you want authentication, you're really looking for a trusted signature on the user ID, fine. You are confusing authenticity and trust. I you visit Bob and he gives you his fingerprint, and when you get home you see that it matches the one on his key, then the key is authenticated. If you now get Marys key, with a signature from Bob, this does not make Marys key authenticated! Bob might not know much about security, and have been tricked to signing a false key. He might secretly hate you and have created Marys key himself. Someone might hold his cat hostage and force him to sign false keys. The point is that even if Bob is your best friend and a security guru who has no cat, his signature is still not a 100% guarantee that the key really belongs to Mary. All the signature provides is various degrees of trust. You are apparently not up to date on something called traffic analysis. I suggest you look into it. What you're talking about here is probably a pipe dream. I have an account on a server run by a trusted party, which has an encrypted connection for accessing e-mail accounts. Most of my friends have accounts on the same server, so our messages to each other never leaves the server. Traffic analysis will reveal what time you are active, and how much data you are transferring. To only way to protect against it is to download and upload all the time at a constant rate. Not worth it in my situation. 1. Stop posting to crypto mailing lists that keep public archives. Creating an electronic paper trail of yourself saying I'm concerned about getting raided by the cops, please help me figure out how to protect my electronic privacy is not a very smart thing to do. I don't think there's anything wrong with saying that I want to protect my privacy. I think if asked if they care about privacy, most people would answer yes. I have been sent letters by the police on several occasions telling me that my phone has been listened to (by law they have to inform you of this some time after). I had my car confiscated and searched. So if I know they are interested in me, surely the strange thing would be if I did not try to protect my privacy? I never said I was concerned about getting raided, I said if someone else got raided it's not good if they find info about me there. 2. Hire an information security professional. GnuPG can be part of a security solution, it can even be a very effective part, but it is not magic fairy dust. You will not find privacy or security just by sprinkling a little magic fairy dust here and there and thinking that it will just work. Heh, I certainly don't think that only encrypting e-mail and signing backups with GnuPG will somehow make all aspects of my life secure. I don't know how you got this impression. I also use TrueCrypt for whole disk encryption, BCWipe for secure deletion, TOR for anonymity, a good firewall, and all my machines run Linux and my supersecure machine is never connected to the Internet.
Re: Questions about generating keys
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. If the amount of resources are so small that even combined they are insignificant, then why not use both? Because there is no such thing as an 'insignificant' amount of resources. Everything has a price associated with it. The trick is to get the most bang for your buck. User IDs do not provide any authentication, okay, that much is true. If you want authentication, you're really looking for a trusted signature on the user ID, fine. You are confusing authenticity and trust. Please read the manual. I am not confusing the two. Authentication of a user ID is provided by a trusted signature. Period, end of sentence. I you visit Bob and he gives you his fingerprint, and when you get home you see that it matches the one on his key, then the key is authenticated. No. You also have to trust that Bob isn't playing a game with you. If you now get Marys key, with a signature from Bob, this does not make Marys key authenticated! Yes. Like I said: you're really looking for a _trusted_ signature. Clearly, in this case you do not trust Bob to make signatures that are in accordance with your security policy. point is that even if Bob is your best friend and a security guru who has no cat, his signature is still not a 100% guarantee that the key really belongs to Mary. All the signature provides is various degrees What world do you live in which offers total assurances of anything other than the inevitability of death and taxes? This is not a game of certainties. Security is a game of probabilities. Anyone who insists on absolutes needs to stop using computers. Traffic analysis will reveal what time you are active, and how much data you are transferring. More importantly in the case you're describing, to whom. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Nigel Brown wrote: I should have known better than to doubt Mr Hansen. Nonsense! Mr. Hansen thrives on being doubted as this is what keeps Him on His toes. :-D *LOL* Seriously; any time You Question a statement for reasons other than That's not what I wanted to hear You should challenge the speaker. :) JOHN ;) Timestamp: Friday 24 Aug 2007, 18:56 --400 (Eastern Daylight Time) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8-svn4570: (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: My Homepage: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJGz2JLAAoJEBCGy9eAtCsPjUUH/1OmIxnxFdOqmPUjsHI0V+yv fbknTTCACxWVzmRLVl5WuE/aLgfvywTQ4bp/ldOAj03FbDd25sI5KxNSi0jB60E1 PAFmiayRNY5bdchGzwRivD4i/ygQ0Iuu4l8x5r9amV02Iyw7OybhQ05NrVIkNKjN QC5ZdYXSPiq9VfpZrO8nMNkaJbBo4AVnu9EfU9Yo8AJXEDaQKXzEB2KiJgS5xLc+ hf4ZbY+KHzJw5guQHK52s9wX58oyFjVY5jLi9MaMopaDHAXhJzuH3Dtft9Fu0cUH FbANWSx8JKy63Um78jnDUWMa6+vrisu4l4yHYnJmYNnTDxN0m3GnhIHzeXINL5k= =ionx -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Oskar L. wrote: Traffic analysis will reveal what time you are active, and how much data you are transferring. To only way to protect against it is to download and upload all the time at a constant rate. Not worth it in my situation. It will also reveal just who communicates with whom and how often; as well as the amount of data sent. This data, with analysis is the basis behind targeting where missiles search warrants are delivered. Think of it as a blind man locating the hub of a bicycle wheel by feeling the spokes. :-D JOHN ;) Timestamp: Friday 24 Aug 2007, 19:03 --400 (Eastern Daylight Time) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8-svn4570: (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: My Homepage: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJGz2P0AAoJEBCGy9eAtCsPXSgH/3YE7/bnna8gtpzYW7G+EPaw v9Wt/W0qJHNrl2sxkS4x7ekf+zwfYyAFSeKs0GeZbOC5SYJQs73mC0HDbeq39tGu nJjbGhC+JQBDxjaxjozZQhGEd+ifsmrNrmOH1kEREI4EqQFnnj8DzTG+Iiu//HNX +sQlLU1QH+ePMcwkzeKFb0RjQ2JyRo6g0eAY/3q9BdtWrR5ylv9433TNu6hQ6ahI 98ESyjQf6mDd5gq1z4FDf/h9YSpu4SKCAnrWllVrJ8sxLWMzbVfVzg9c7ufQaf6+ n0eb8NRT4FFcHwtNUHs/f/g9JxNTuo/KVs+mcI98VwSZ/M04qRgxVjaTuDT8Z18= =yBzc -END PGP SIGNATURE- ___ 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. wrote: I only meant to point out that a birthday attack would have a much better chance of finding a collision than a second preimage attack. I'm sorry if I made it sound trivial, I know it's not. I just tried to give an example of how it works that would be easy to understand. Well, except that your attack isn't a birthday attack. A birthday attack involves making a ton of different messages and checking _all_ messages created to find _any_ collision. Your attack involves taking one particular message and creating permutations of it, one after another, looking for a collision with your particular message. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
Robert J. Hansen wrote: Because there is no such thing as an 'insignificant' amount of resources. Everything has a price associated with it. The trick is to get the most bang for your buck. Well I guess what's insignificant to one person might not be to another. I know some spammers get addressed by scanning common names, so I would get [EMAIL PROTECTED] instead of [EMAIL PROTECTED] I consider having to type 3 digits more a day to be an insignificant hassle, and well worth the extra security. Robert J. Hansen wrote: I you visit Bob and he gives you his fingerprint, and when you get home you see that it matches the one on his key, then the key is authenticated. No. You also have to trust that Bob isn't playing a game with you. That the key is authentic means that it is the key Bob wanted you to have, and has not been changed in a man-in-the-middle attack or by any other means. That's all. You can be sure of this if the fingerprint matches. You do not need to trust Bob for the key to be authentic. Bob can be the biggest liar in the world, you still have his authentic key. To be secure you also need to trust him. Authentication can exist without trust, and trust can exist without authentication, but only both combined creates security. Think of it this way. Let's say you don't trust Google for some reason. Then you go to https://mail.google.com, and verify that the SSL certificate is correct, so you can be sure your not on a phishing site. Would you now claim that the site isn't authentic, just because you don't trust Google? Or if you see someone you don't trust, can your eyes then not authenticate to you that the person is who you think they are? Of course they can, because authentication does not require trust, it's security that does. If you do not trust Bob, you can do gpg --edit-key Bob, then type trust. You will be given these options: 1 = I don't know or won't say 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully 5 = I trust ultimately If you now get Marys key, with a signature from Bob, this does not make Marys key authenticated! Yes. Like I said: you're really looking for a _trusted_ signature. Clearly, in this case you do not trust Bob to make signatures that are in accordance with your security policy. Even if we trust Bob completely, then his signature would still just add trust to Marys key, not authentication. We _trust_ that Bob has checked Marys fingerprint carefully before signing her key, we have not _verified_ that he has. What world do you live in which offers total assurances of anything other than the inevitability of death and taxes? A world in which medical advances will get rid of death and crypto-anarchism will get rid of taxes? But seriously, when it comes to people trust is the best you can have. You know your friend is able to hit you in the face, but you have good reasons for strongly believing he/she won't. But that's as good as it gets. There's no proof. You can't be 100% sure. Total assurance can be found in mathematics. You don't trust that 5+5=10, you know it. Oskar ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys (hash firewalls)
Well, except that your attack isn't a birthday attack. A birthday attack involves making a ton of different messages and checking _all_ messages created to find _any_ collision. Your attack involves taking one particular message and creating permutations of it, one after another, looking for a collision with your particular message. No, in my example I used two, not one messages (pictures) and created permutations of both, and then compared both groups of hashes against each other. Oskar ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
On Thu, Aug 23, 2007 at 05:11:35AM +0300, Oskar L. wrote: Ok, so RSA isn't always significantly faster, as I thought it was. I had read somewhere that it was, (probably on this list) and my own testing with my 4GB backup files showed RSA to be notably faster. Make sure you're comparing apples to apples here. If you're comparing RSA to DSA, you need to measure signature speed. If you want to compare RSA encryption speed, you need to compare it against an encryption algorithm like Elgamal. DSA doesn't encrypt. So would it be fair to sum up the differences like this: - for signing DSA is faster, for verification RSA is faster, but there's not much of a difference. There is a substantial difference, but no real difference in practice for most uses of OpenPGP. (I could make up a case where it might make a difference, but it would be an odd, clearly invented, case). - OpenPGP implementations must support DSA, but supporting RSA is optional, but both gpg and PGP support RSA, so there's not much of a differance. Yes. - original DSA limited to 1024 bit keys and 160 bit hashes. Yes. - DSA signatures are smaller. Yes. DSA signatures are relative to the size of the hash used. RSA signatures are relative to the size of the key. - updated DSA, aka DSA2, equal to RSA when it comes to the lenghts of keys and hashes. Not exactly equal, but roughly equal. The largest DSA2 key that GPG will generate is a 3072 bit key that uses a 256-bit hash. The largest RSA key that GPG will generate is 4092 bits long. 3072/256 is roughly balanced in strength (that is, the key and the hash are about the same strength). 4096, the RSA limit, isn't felt to be significantly stronger than 3072 (the next step after 3072 is actually 7680 in the NIST key management publication 800-57). - RSA has a hash firewall Yes. If there are no other significant differences that I have missed, since I want a key larger that 1024 bits, it must be a DSA2 or RSA key. RSA gets a minus for not being required by OpenPGP, but only a small one since it is supported anyway. DSA2 gets minus points both for lack of support in older versions of PGP, and for lack of a hash firewall. RSA still seems better to me, but not by as much as I previously thought. It's important to note that we're talking about tiny fiddling details here. Either path is so vastly stronger than is usually needed that this is rather like discussing whether a 1001-foot fence is better than a 1000-foot fence: sure, 1001 sounds better, but if you have an attacker that could get over a 1000 foot fence, it's safe to assume they can make a pretty good crack at the remaining foot. If you're really worried about people with older software not being able to use your key, that's a strong reason to not choose DSA2. In that case, I'd make a RSA primary key, an encryption subkey of whatever algorithm you like, and then a DSA subkey that you actually use to sign with. Do avoid signing documents with a big RSA key. It's really annoying to the recipient. So they accepted RSA into the standard, while it was still restricted by patents, as long as it wasn't made the default? I took for granted that an open standard like OpenPGP would not have accepted any patented stuff into the standard, and that RSA was added later, after the patents ran out. I'm a bit sad to find out I was wrong, I was under the impression that OpenPGP only allowed completely free and open algorithms. It's way more complex than that (both for OpenPGP and other IETF specs). Check out the significant number of patent-related documents on the IETF website. There are (at least) two full RFCs on this topic alone. Remember also that before OpenPGP was OpenPGP, it was just PGP: a good bit of the OpenPGP standard was standardized before the IETF was brought in. Again, historical and occasional legal issues that aren't really relevant any longer. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
Robert J. Hansen wrote: In the battle between armor and warhead, _always_ bet on the warhead. Playing defensively and trying to make an email address invisible is going to be an exercise in frustration. They always get seen. They always get spammed. Play defensively and you lose. Well if you need to have an e-mail address available to the general public then this is certainly true. Spammers have even been known to hire cheap labor to surf the web looking for e-mail addresses and filling in spam in forms, so even hiding your address in a blurred upside-down JPEG won't help. If you have security unaware friends who type in your address on send your friend an ecard type of sites, or have you in their address book on their Windows box full with spyware, then the spammers will get your address, no matter what you do. But if you don't need a public address, and only have security conscious friends, then I would think you have a good change of staying of the spammers lists. Yahoo! has a nice free service called AddressGuard. You just create a base name (foo) and append an ID (bar) to it, and now you have a disposable address: [EMAIL PROTECTED], witch delivers mail to your normal Yahoo! address. You can have 500 different IDs, so you can give a different address to each of your friends, and check who is leaking your address. Whitelisting, graylisting, blacklisting, Bayesian filters, even lawsuits if you're so inclined--those are all active measures which force the spammers to adapt to your actions. That gives you a measure of initiative back. You're no longer playing pure defensive. Those are all good things, but just because we have them does not mean that it's not a good idea to try to stay of the spammers list in the first place. Personally I'd like to see more aggressive anti-spam measures, like the ones taken by Blue Frog. If you like, I'll ask the antispam research group here at UI if they think there's anything to be gained by omitting an email address from a key. User IDs do not provide any authentication, so security wise they are useless. The most secure thing would be not to have one at all, and have my friends remember that key number belongs to me. This way, if my friends get raided, it will be more difficult or impossible for the police to figure out that it's my key. But since this is very inconvenient, I decided to sacrifice a little security for convenience, by putting my first name in the user ID. I don't provide an e-mail address mainly because it's easier to change my e-mail address if I don't have to update my key, but this undeniably also makes things a little harder for spammers, since it's one less place they can find my e-mail address. It might also help in a deniability claim. I don't however think that it's too much to ask that people remember witch e-mail address goes with witch key. Oskar ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
Sven Radde wrote: I am paranoid, too. Could someone therefore please explain to me what a hash firewall actually is (possibly off-list)? In an RSA signature, data about what algorithm was used in a signature is, itself, part of the signed data. You can't lie about a signature algorithm without tampering with the message and making the signature fail to verify. In DSA, the data is not part of the signed data. This allows you to lie. This has potential problems if one of the supported hashes becomes so catastrophically weak that second-preimage attacks become feasible. SHA-1 may be basically dead as far as crypto goes, but it is a _long_ way from a second-preimage attack. The paranoid interpretation of this: Let's speculate that tomorrow, Shengdong University continues their trend of eye-popping crypto research and announces a second-preimage attack against SHA-1. You migrate to RIPEMD160 or truncated SHA256 or what-have-you as a result. An attacker wants to forge one of your new RIPEMD160-based signatures. An attacker gets a good RIPEMD160-based signature from you. This is basically one very long binary sequence, which says hey, if the message you're reading hashes out to this binary sequence, then yes, it's for real. I construct a new message, saying I, Sven Radde, agree to pay Rob Hansen one frosty cold pint of bitters. I wave the dead chicken over it, or whatever Shengdong U. says I have to do, in order to make it hash out to the exact same binary sequence as the one your signature says is authentic. I lift your RIPEMD160 signature and place it on my new forged message. I proceed to then lie and say This message used SHA-1 as a digest. I give it to your local barkeep. He looks at the message, SHA-1s it, gets the binary sequence I constructed. He compares it against your signature block, which says hey, if the message you're reading hashes out to this binary sequence, then yes, it's for real. Your barkeep pours me a nice cold frosty pint of bitters--hey, I'm a barbaric American and I drink my beer _cold_, thank you very much--and puts the bill for it on your tab. I have now defrauded you by using a forged message. And it's all made possible by the lack of a hash function firewall. The practical paranoid interpretation of this: A second-preimage attack on SHA-1 would be a mathematical advance of such massive proportions that worrying about its consequences for DSA signatures is kind of dumb. If you stay up late at night wondering what will ever happen to Deal Or No Deal in the days after a meteor hits Earth, then you're probably the type of person who worries about what happens to DSA signatures after a second-preimage attack on SHA1. The rest of the world, however, will have much more important things to worry about. ... Personally, I myself subscribe to the practical paranoid view. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
Oskar L. wrote: But if you don't need a public address, and only have security conscious friends, then I would think you have a good change of staying of the spammers lists. 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. Those are all good things, but just because we have them does not mean that it's not a good idea to try to stay of the spammers list in the first place. Sure it is. All of us are constrained by external forces. We don't have as much time, as much energy, as much money, as much anything as we want. We have to make tradeoffs. That's called economics. If I know that one sort of antispam measure is going to reduce the spam I receive 100-fold over the reduction produced by another antispam measure... and the 100-fold measure takes the same amount of resources as the other one... then why should I ever use the second measure? I get a 100-fold reduction from X amount of time and labor, or a 101-fold reduction from a 2X amount of time and labor. This is really simple to me; I'm going to take the 100-fold reduction and spend the extra X time goofing off, or visiting my nephews, or grabbing lunch with my sister, or doing thesis research, or... Use the most effective measures available to you, and know when to stop. If I had 2X units of time, I still wouldn't use the two measures to get a 101-fold reduction in spam. I'd spend X time using the technologies currently available, and I'd spend X time researching new technologies to try and kick the 100-fold technology up to 1000-fold. That'd be a very efficient and economical use of time. User IDs do not provide any authentication, so security wise they are useless. Whoawhoawhoawhoa. I don't know where you got this from, but it's very wrong. User IDs do not provide any authentication, okay, that much is true. If you want authentication, you're really looking for a trusted signature on the user ID, fine. But security wise they are useless is just barking madness. Really. The most secure thing would be not to have one at all, and have my friends remember that key number belongs to me. This way, if my friends get raided, it will be more difficult or impossible for the police to figure out that it's my key. You are apparently not up to date on something called traffic analysis. I suggest you look into it. What you're talking about here is probably a pipe dream. If you're that concerned about getting raided, there are two things you need to do right now. 1. Stop posting to crypto mailing lists that keep public archives. Creating an electronic paper trail of yourself saying I'm concerned about getting raided by the cops, please help me figure out how to protect my electronic privacy is not a very smart thing to do. 2. Hire an information security professional. GnuPG can be part of a security solution, it can even be a very effective part, but it is not magic fairy dust. You will not find privacy or security just by sprinkling a little magic fairy dust here and there and thinking that it will just work. If your needs are this high-level, you need the services of an information security professional. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At 04:11 2007-08-23, Oskar L. wrote: - --snip-- Robert J. Hansen wrote (regarding DSA2 keys): The latest versions of PGP support them. That's good news. Can it also create them? But there are probably still many using older versions. I know some who refuse to update from 6.5.8. Some people stick to PGP 8.1, a version fairly compliant with GPG. See below. David Shaw wrote: Now that DSA2 is here, there aren't really that many benefits to RSA (and I say this as someone with an RSA key). In theory, DSA is better because it is required by OpenPGP: you won't be able to find any OpenPGP implementation that doesn't handle it. This is not true of RSA (it's legal for a program to reject it just because it is RSA). In practice, that doesn't happen much because the big two, PGP and GPG, both handle RSA. - -- snip -- So would it be fair to sum up the differences like this: - for signing DSA is faster, for verification RSA is faster, but there's not much of a difference. - OpenPGP implementations must support DSA, but supporting RSA is optional, but both gpg and PGP support RSA, so there's not much of a differance. - original DSA limited to 1024 bit keys and 160 bit hashes. - DSA signatures are smaller. - updated DSA, aka DSA2, equal to RSA when it comes to the lenghts of keys and hashes. - Of PGP, only the newest version support DSA2 keys. - RSA has a hash firewall If there are no other significant differences that I have missed, since I want a key larger that 1024 bits, it must be a DSA2 or RSA key. RSA gets a minus for not being required by OpenPGP, but only a small one since it is supported anyway. DSA2 gets minus points both for lack of support in older versions of PGP, and for lack of a hash firewall. RSA still seems better to me, but not by as much as I previously thought. - --snip -- Oskar PGP 8.1 verifies SHA-256 hashes made by large RSA-keys, but NOT any signatures made by DSA2-keys. Signing algorithm not supported. To create DSA2-keys with GPG you have to use the option enable-dsa2. Snoken -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) - GPGrelay v0.959 iD8DBQFGzXNCWisObvnr8tQRAuSVAJ9p0FHy+Xgp+qetg00FBDDlf2/7eACfTu6t RONfGdW5At2219R7Y4VZXL4= =QFqQ -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
On Thu, Aug 23, 2007 at 12:40:02PM +0300, Oskar L. wrote: Robert J. Hansen wrote: In the battle between armor and warhead, _always_ bet on the warhead. Playing defensively and trying to make an email address invisible is going to be an exercise in frustration. They always get seen. They always get spammed. Play defensively and you lose. Well if you need to have an e-mail address available to the general public then this is certainly true. Spammers have even been known to hire cheap labor to surf the web looking for e-mail addresses and filling in spam in forms, so even hiding your address in a blurred upside-down JPEG won't help. [] I'll tell you something. I have three public email addresses that I use almost exclusively, and one doubles as my Jabber ID, and I never used obsfuctaion or protection: all they do is irritate users and decrease chance that someone who should be able to contact me, can't. Yet, I receive much less spam to my mbox than for example to comments on my blog. Why? I use some not very complicated precautions. Actually, as I said before one of two spams slip in a month, sometimes one more, sometimes none at all. All those things that you describe involve lot of effort on your and your correspondent's side, and are weak - if someone who has your address gets a trojan, your address leaks out. If someone accidentally puts server log files on the net, your address leaks out, when someone writes to your wrong address (like sending private reply to email address) the communication won't work. What are you tring to do, is like full time wearing full biosafety hazmat suit with closed air circulation just to avoid getting common cold. It won't work this way or another, the air will run out at some point or the suit will wear and tear where and when you are not looking. And you are a big inconvenience to your peers. What I'm saying is that this approach is stupid, and wasteful of time and resources. It seems secure, gives this warm and fuzzy feeling, but it isn't. It is like taking your shoes in the airport, but what if someone smuggles some C4 in a buttplug and blows it with electronics of his ipod? If you have security unaware friends who type in your address on send your friend an ecard type of sites, or have you in their address book on their Windows box full with spyware, then the spammers will get your address, no matter what you do. All people are security unconscious and some point.s But if you don't need a public address, and only have security conscious friends, then I would think you have a good change of staying of the spammers lists. And what if I haven't such friends? Whitelisting, graylisting, blacklisting, Bayesian filters, even lawsuits if you're so inclined--those are all active measures which force the spammers to adapt to your actions. That gives you a measure of initiative back. You're no longer playing pure defensive. Those are all good things, but just because we have them does not mean that it's not a good idea to try to stay of the spammers list in the first place. Personally I'd like to see more aggressive anti-spam measures, like the ones taken by Blue Frog. It is not good idea, because you can't in the same way you can't quit address lists of influenza viruses and meteorite strikes. User IDs do not provide any authentication, so security wise they are useless. The most secure thing would be not to have one at all, and have my friends remember that key number belongs to me. This way, if heh you are expecting big things of people and if someone offers them chocolate[1] to give out your secret number? [1] research shows that people are willing to give out actual passwords in exchange for chocolate my friends get raided, it will be more difficult or impossible for the police to figure out that it's my key. But since this is very inconvenient, I decided to sacrifice a little security for convenience, by putting my first name in the user ID. I don't provide an e-mail address mainly because it's easier to change my e-mail address if I don't have to update my key, but this undeniably also makes things a little harder for spammers, since it's one less place they can find my e-mail address. It might also help in a deniability claim. I don't however think that it's too much to ask that people remember witch e-mail address goes with witch key. if you do things that can get you raided by police, that changes the threat model but on the other hand, surveillance usually means communication intercepts so the interceptors will know that communciations encrypted with this particular key and id go to you Alex -- JID: [EMAIL PROTECTED] PGP: 0x46399138 od zwracania uwagi na detale są lekarze, adwokaci, programiści i zegarmistrze -- Czerski ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
Oskar L. [EMAIL PROTECTED] writes: Yahoo! has a nice free service called AddressGuard. [...] Spamgourmet¹ has offered this and more since October 2000. Footnotes: ¹ http://www.spamgourmet.com/ -- Steven E. Harris ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Questions about generating keys
I'm about to generate a new keypair, and got a few questions. I have many e-mail addresses and change them frequently, and therefore I don't want to have one in my public key. (Also because I'm afraid of getting spam.) I think this would be easier than having to update a lot of user IDs. Are there any any drawbacks in not having an e-mail address in the public key? Are there any widely used applications that will expect one, and not work if none is found? Why is there no way to generate a RSA keypair in one step, like when you create a DSA/Elgamal keypair? Why do I first have to create a signing key, and then in a separate step create an encryption key? This is annoying. Name must be at least 5 characters long Why? There are probably many people who like to go only by their first name, and have a 3 or 4 character name. Is there any way to manually set the time that will be used for the creation time? Or do I have to change the system time if I don't want to use the current time? I'm a bit of a perfectionist, and think 00:00:00 looks much better than something like 01:42:57. Oskar ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
Oskar L. wrote: Are there any any drawbacks in not having an e-mail address in the public key? Not especially. Are there any widely used applications that will expect one, and not work if none is found? Not to my knowledge. Why is there no way to generate a RSA keypair in one step, like when you create a DSA/Elgamal keypair? Why do I first have to create a signing key, and then in a separate step create an encryption key? This is annoying. 1. Because the developers don't feel it's necessary, and nobody's yet submitted a patch. 2. Why do you need an RSA keypair? The overwhelming majority of users are best served by sticking with the defaults--which, in this case, means a DSA/Elgamal keypair. Name must be at least 5 characters long Why? There are probably many people who like to go only by their first name, and have a 3 or 4 character name.' 1. Because the developers don't feel it's necessary, and nobody's yet submitted a patch. 2. RFC2440 is officially neutral about the content of a user ID packet, except that by convention it's an RFC822-style address. Speaking for myself, I'm glad GnuPG enforces a minimum; it reduces the likelihood that some poorly-conformant implementation will have a psychotic break from reality when it sees a user ID packet with length 0. GnuPG's limit is, as near as I can tell, completely arbitrary. That doesn't make it a bad choice. If the spec gives no guidance (at least, none I can see in section 5.11), then any decision whatsoever is arbitrary. Allow zero-length? Arbitrary. Allow only names of 17 characters? Arbitrary. Require at least five-letter names? Arbitrary. The ultimate metric is not whether the choice is perfect; it's whether the choice makes sense for the great majority of users. Is there any way to manually set the time that will be used for the creation time? Or do I have to change the system time if I don't want to use the current time? I'm a bit of a perfectionist, and think 00:00:00 looks much better than something like 01:42:57. There is not, and I recommend against changing your system time just to get a 'perfect' key. A key is a mathematical device which allows us to utilize trust relationships over a widely dispersed network. A perfect key is one which best contributes to the confidence and trust of the network. If I see that you've got a key date of 00:00:00, my first thought is going to be that you've played hob with your system time and carefully doctored your key. That is not going to cause me to have trust in you or your key. Doctoring a key in this way is probably ultimately against your own interests. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
On Wed, Aug 22, 2007 at 01:06:18PM +0300, Oskar L. wrote: I'm about to generate a new keypair, and got a few questions. I have many e-mail addresses and change them frequently, and therefore I don't want to have one in my public key. (Also because I'm afraid of getting spam.) I think this would be easier than having to update a lot of user IDs. Are there any any drawbacks in not having an e-mail address in the public key? Are there any widely used applications that will expect one, and not work if none is found? Yes, common sense. if you submit your key to a keyserver, there should be some way to distinguish your key from hundreds of other having the same short name, when searching for a key. Sidenote: you are getting spammed anyway, it is better to invest in filtering infrastructure (greylisting, spamassassin, bogofilter), than play whack-a-mole with spammers, with you being the mole. Is there any way to manually set the time that will be used for the creation time? Or do I have to change the system time if I don't want to use the current time? I'm a bit of a perfectionist, and think 00:00:00 looks much better than something like 01:42:57. It looks unnatural and doctored. Alex -- JID: [EMAIL PROTECTED] PGP: 0x46399138 od zwracania uwagi na detale są lekarze, adwokaci, programiści i zegarmistrze -- Czerski ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
Oskar L. wrote: Name must be at least 5 characters long Why? There are probably many people who like to go only by their first name, and have a 3 or 4 character name. It's generally considered useful to follow the typical format for a user id (FirstName LastName [EMAIL PROTECTED]). You are free to ignore this and the --allow-freeform-uid option will bypass all checks on the format of the user id. -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ That men do not learn very much from the lessons of history is the most important of all the lessons of history. -- Aldous Huxley Collected Essays, 1959 pgpDhSSbChbb9.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
On Wed, Aug 22, 2007 at 01:06:18PM +0300, Oskar L. wrote: I'm about to generate a new keypair, and got a few questions. I have many e-mail addresses and change them frequently, and therefore I don't want to have one in my public key. (Also because I'm afraid of getting spam.) I think this would be easier than having to update a lot of user IDs. Are there any any drawbacks in not having an e-mail address in the public key? Are there any widely used applications that will expect one, and not work if none is found? Yes. Mail programs tend to fetch keys by email address (out of necessity - that's usually all they know about the person being mailed). Why is there no way to generate a RSA keypair in one step, like when you create a DSA/Elgamal keypair? Why do I first have to create a signing key, and then in a separate step create an encryption key? This is annoying. No real reason, except it would make the list of key types very long if every possible combination was listed (RSA primary/Elgamal subkey, DSA primary/RSA subkey, RSA primary/RSA subkey, DSA primary/Elgamal subkey). Name must be at least 5 characters long Why? There are probably many people who like to go only by their first name, and have a 3 or 4 character name. It's not common, and keeping a 5 character name helps prevent errors (mistyping). If you really have a name that short, you can use the --allow-freeform-uid to override the test. Is there any way to manually set the time that will be used for the creation time? Or do I have to change the system time if I don't want to use the current time? I'm a bit of a perfectionist, and think 00:00:00 looks much better than something like 01:42:57. As it happens, this will probably be possible in an upcoming version, but for other reasons. That said: I wouldn't bother - it changes nothing about the key and is completely cosmetic. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
Robert J. Hansen wrote: 2. Why do you need an RSA keypair? The overwhelming majority of users are best served by sticking with the defaults--which, in this case, means a DSA/Elgamal keypair. I prefer RSA keys because - DSA does not have a hash firewall. - They don't have a 1024 bit limit, like DSA has. I know DSA2 can have larger keys, but last I heard PGP can't use them. - The hash used is not limited to 160 bits, like it is with DSA. - RSA is faster. I can't understand why RSA isn't the default. The only argument defending DSA I've heard is that DSA creates smaller signatures. Is this really so important to people that they are willing to give up all the benefits of RSA for it? David Shaw wrote: No real reason, except it would make the list of key types very long if every possible combination was listed (RSA primary/Elgamal subkey, DSA primary/RSA subkey, RSA primary/RSA subkey, DSA primary/Elgamal subkey). I understand, but surely an RSA keypair must be such a common thing that it could have it's own option? What I find really strange is that the archives mention a sixth option, (6) RSA (sign and encrypt), but version 1.4.6 gives me: Please select what kind of key you want: (1) DSA and Elgamal (default) (2) DSA (sign only) (3) DSA (set your own capabilities) (5) RSA (sign only) (7) RSA (set your own capabilities) Why was the sixth option removed? By the way, is there a security or performance difference between a RSA (sign and encrypt) keypair with no subkeys, and a RSA (sign only) keypair with a RSA (encrypt only) subkey? David Shaw wrote: Is there any way to manually set the time that will be used for the creation time? Or do I have to change the system time if I don't want to use the current time? I'm a bit of a perfectionist, and think 00:00:00 looks much better than something like 01:42:57. As it happens, this will probably be possible in an upcoming version, but for other reasons. Nice! I'm curious about what these reasons are. Alex wrote: Yes, common sense. if you submit your key to a keyserver, there should be some way to distinguish your key from hundreds of other having the same short name, when searching for a key. Sorry, I forgot to say that I don't use any keyservers. Only my friends can get my private e-mail address and private public key. James wrote: - E-mail clients using PGP won't be able to automatically know which key to use when e-mailing you - they'd have to setup specific mappings. That's ok, since they would have the same problem if the address in my key differed from the one in their address book. Since not specifying an e-mail address doesn't seem to go against the OpenPGP specification, I think I won't specify one when I create my new key. Todd wrote: ...the --allow-freeform-uid option will bypass all checks on the format of the user id. I'll keep that in mind in case I'll ever need it. Thanks everybody for your anwsers! -Oskar ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
On Wed, 22 Aug 2007 13:06:18 +0300 (EEST) Oskar L. [EMAIL PROTECTED] wrote: Name must be at least 5 characters long Why? There are probably many people who like to go only by their first name, and have a 3 or 4 character name. Use gpg --gen-key --allow-freeform-uid (from 'man gpg') best regards Paul -- It isn't worth a nickle to two guys like you or me, but to a collector it is worth a fortune signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 John Clizbe wrote: There's no guarantee that your key won't end up on a keyserver nor is there one that your private email address won't leak into the public, All it takes is 1 inadvertent click of 'Refresh All Keys' or a well intentioned sharing of the 'Gift' of a Signature. :( Public Keys are like 'Secrets'; When _only_ You have/know it, it's Secret.whenever it's shared it's...well, Public. JOHN ;) Timestamp: Wednesday 22 Aug 2007, 16:48 --400 (Eastern Daylight Time) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8-svn4556: (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: My Homepage: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJGzKFHAAoJEBCGy9eAtCsPm5UH/0gCHp54spcykpsSG87sluvp ix1jGDgJvnLSLr6QLci3vN5sVlV+5W17TOdmCWujz+0pucVDA3QOc0NwdK2kMoGQ /1766wV75dA3lluBvr2/fWaAOUaoyUkw6JqEEINEbwUbwObqFn4FA3RCjTojYC1I njHw4AEt7158dIBaCpvM45xvcFCxU8zbGatO2Kf6v879da5SfsIlfAahnCpDc+xf tbg1G6sjldoeGpbUMWqntDeQgKL6/RyuaZcE6vlWt+E8kLROD14c3WQqIgxQvHn+ GQUA4yn6yxsJt3oTAAINDGpfht0fIWoQJjKx18nq8icCRJBBulOe9HB9RPhE7DI= =dDDk -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
On Wed, Aug 22, 2007 at 03:34:50PM -0500, John Clizbe wrote: Alex wrote: Yes, common sense. if you submit your key to a keyserver, there should be some way to distinguish your key from hundreds of other having the same short name, when searching for a key. Sorry, I forgot to say that I don't use any keyservers. Only my friends can get my private e-mail address and private public key. Relying on the 'highly effective Security via Obscurity model, huh? There's no guarantee that your key won't end up on a keyserver nor is there one that your private email address won't leak into the public, There were people that submitted their whole keyrings to keyservers. And yesterday I got spammed to address that I created for one-time use for one person, and never gave publicly nor to anyone else. a -- JID: [EMAIL PROTECTED] PGP: 0x46399138 od zwracania uwagi na detale są lekarze, adwokaci, programiści i zegarmistrze -- Czerski ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
Oskar L. wrote: - They don't have a 1024 bit limit, like DSA has. I know DSA2 can have larger keys, but last I heard PGP can't use them. The latest versions of PGP support them. - RSA is faster. If you are repeatedly encrypting and/or decrypting enormous files, then yes, this is potentially an issue. Otherwise, there is no practical difference in speed you will notice. I can't understand why RSA isn't the default. The OpenPGP specification came out in the late nineties. RSA did not enter the public domain until August of 2000. The IETF refused--rightly so--to make a patented algorithm the default OpenPGP algorithm. The only argument defending DSA I've heard is that DSA creates smaller signatures. Is this really so important to people that they are willing to give up all the benefits of RSA for it? This implicitly casts RSA as being somehow universally superior. It's not. Nor is it inferior. In a couple of very narrow fields, RSA is superior. In others, DSA is probably superior. In yet others, Rabin signatures are probably best. (Me, I've wondered for years why OpenPGP doesn't support Rabin; it's a beautifully elegant algorithm. And then I kick myself and say duh, to keep the number of algorithms down, just like with Lamport signatures and WHIRLPOOL!, and go on with my business.) Why was the sixth option removed? Because it's a deprecated key style. There's nothing inherently wrong with it, but most authorities today recommend using separate signing and encryption keys. By the way, is there a security or performance difference between a RSA (sign and encrypt) keypair with no subkeys, and a RSA (sign only) keypair with a RSA (encrypt only) subkey? Only when it comes to recovering from a security-related incident. If the cops come by and force you to give the private part of a key used to encrypt a message, fine, you can do so without yielding your signing key. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
On Wed, Aug 22, 2007 at 08:36:36PM +0300, Oskar L. wrote: Robert J. Hansen wrote: 2. Why do you need an RSA keypair? The overwhelming majority of users are best served by sticking with the defaults--which, in this case, means a DSA/Elgamal keypair. I prefer RSA keys because - DSA does not have a hash firewall. - They don't have a 1024 bit limit, like DSA has. I know DSA2 can have larger keys, but last I heard PGP can't use them. I'm not sure if that is still true or not, but either way, if PGP doesn't use them now, it will soon. The new OpenPGP spec supports large DSA (so-called DSA2) keys. - The hash used is not limited to 160 bits, like it is with DSA. Same here. DSA2 supports larger hashes. - RSA is faster. This is actually not completely true. DSA makes signatures faster than RSA. RSA verifies signatures faster than DSA. Since most signatures are verified more often than they are generated, this is generally stated as RSA being faster, but in OpenPGP usage, this is almost always irrelevant. Unless you're issuing thousands of signatures a second, the time needed to read the files, and do the hashing is far more significant. I can't understand why RSA isn't the default. The only argument defending DSA I've heard is that DSA creates smaller signatures. Is this really so important to people that they are willing to give up all the benefits of RSA for it? Now that DSA2 is here, there aren't really that many benefits to RSA (and I say this as someone with an RSA key). In theory, DSA is better because it is required by OpenPGP: you won't be able to find any OpenPGP implementation that doesn't handle it. This is not true of RSA (it's legal for a program to reject it just because it is RSA). In practice, that doesn't happen much because the big two, PGP and GPG, both handle RSA. So DSA is the default because the OpenPGP standard requires it to be present, and does not require the same of RSA. The reasons behind this were mainly legal stuff and not relevant any longer. What I find really strange is that the archives mention a sixth option, (6) RSA (sign and encrypt), but version 1.4.6 gives me: Please select what kind of key you want: (1) DSA and Elgamal (default) (2) DSA (sign only) (3) DSA (set your own capabilities) (5) RSA (sign only) (7) RSA (set your own capabilities) Why was the sixth option removed? The feature wasn't removed. Option 7 took its place. RSA (sign and encrypt) is the same thing as RSA (set your own capabilities) - just turn on the sign and encrypt flags. By the way, is there a security or performance difference between a RSA (sign and encrypt) keypair with no subkeys, and a RSA (sign only) keypair with a RSA (encrypt only) subkey? No performance difference. There is a minor security difference between one and two keys in that if your key is compromised, with one key you've compromised both your signing and encrypting capabilitles. With two keys, you've only compromised the one. The usual example of this is the police demanding an encryption key from you (which they can do in many places around the world). If you have a subkey for encryption, you could turn over that subkey without affecting your primary key (and thus all the signatures you've gathered and issued). If you don't have a subkey for encryption, you can be forced into turning over the one key, which compromises your signing key as well. David Shaw wrote: Is there any way to manually set the time that will be used for the creation time? Or do I have to change the system time if I don't want to use the current time? I'm a bit of a perfectionist, and think 00:00:00 looks much better than something like 01:42:57. As it happens, this will probably be possible in an upcoming version, but for other reasons. Nice! I'm curious about what these reasons are. Mainly the use of GPG inside anonymous remailers and similar proxies. In cases like that you may want to randomize or force the internal timestamps to hide the original values. James wrote: - E-mail clients using PGP won't be able to automatically know which key to use when e-mailing you - they'd have to setup specific mappings. That's ok, since they would have the same problem if the address in my key differed from the one in their address book. Since not specifying an e-mail address doesn't seem to go against the OpenPGP specification, I think I won't specify one when I create my new key. There is a whole lot of code in the world that really really expects an email address in there. You're free to do what you want, but don't be surprised when something breaks. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions about generating keys
Thanks again for all your answers, I'm really interested in this kind of stuff. Robert J. Hansen wrote (regarding DSA2 keys): The latest versions of PGP support them. That's good news. Can it also create them? But there are probably still many using older versions. I know some who refuse to update from 6.5.8. David Shaw wrote: Now that DSA2 is here, there aren't really that many benefits to RSA (and I say this as someone with an RSA key). In theory, DSA is better because it is required by OpenPGP: you won't be able to find any OpenPGP implementation that doesn't handle it. This is not true of RSA (it's legal for a program to reject it just because it is RSA). In practice, that doesn't happen much because the big two, PGP and GPG, both handle RSA. So DSA is the default because the OpenPGP standard requires it to be present, and does not require the same of RSA. The reasons behind this were mainly legal stuff and not relevant any longer. I wasn't aware of this, thanks for the info! David Shaw wrote: This is actually not completely true. DSA makes signatures faster than RSA. RSA verifies signatures faster than DSA. Since most signatures are verified more often than they are generated, this is generally stated as RSA being faster, but in OpenPGP usage, this is almost always irrelevant. Unless you're issuing thousands of signatures a second, the time needed to read the files, and do the hashing is far more significant. Robert J. Hansen wrote: If you are repeatedly encrypting and/or decrypting enormous files, then yes, this is potentially an issue. Otherwise, there is no practical difference in speed you will notice. Ok, so RSA isn't always significantly faster, as I thought it was. I had read somewhere that it was, (probably on this list) and my own testing with my 4GB backup files showed RSA to be notably faster. David Shaw wrote: Same here. DSA2 supports larger hashes. So would it be fair to sum up the differences like this: - for signing DSA is faster, for verification RSA is faster, but there's not much of a difference. - OpenPGP implementations must support DSA, but supporting RSA is optional, but both gpg and PGP support RSA, so there's not much of a differance. - original DSA limited to 1024 bit keys and 160 bit hashes. - DSA signatures are smaller. - updated DSA, aka DSA2, equal to RSA when it comes to the lenghts of keys and hashes. - Of PGP, only the newest version support DSA2 keys. - RSA has a hash firewall If there are no other significant differences that I have missed, since I want a key larger that 1024 bits, it must be a DSA2 or RSA key. RSA gets a minus for not being required by OpenPGP, but only a small one since it is supported anyway. DSA2 gets minus points both for lack of support in older versions of PGP, and for lack of a hash firewall. RSA still seems better to me, but not by as much as I previously thought. Robert J. Hansen wrote: The OpenPGP specification came out in the late nineties. RSA did not enter the public domain until August of 2000. The IETF refused--rightly so--to make a patented algorithm the default OpenPGP algorithm. So they accepted RSA into the standard, while it was still restricted by patents, as long as it wasn't made the default? I took for granted that an open standard like OpenPGP would not have accepted any patented stuff into the standard, and that RSA was added later, after the patents ran out. I'm a bit sad to find out I was wrong, I was under the impression that OpenPGP only allowed completely free and open algorithms. If the IETF refused to make RSA the default, does that mean that the people behind OpenPGP originally wanted it to be the default, but then had to change it to DSA? Relying on the 'highly effective Security via Obscurity model, huh? There's no guarantee that your key won't end up on a keyserver nor is there one that your private email address won't leak into the public, I would not say that just because someone doesn't willingly make their address available to spammers makes them a believer in security through obscurity. Full disclosure is not a good strategy when it comes to personal information like e-mail addresses, credit card numbers etc. Saying that going through a little trouble to greatly decrease the risk of something bad happening is not worth it because it won't make you 100% secure makes no sense. That's like saying that you can't get 100% protection from dying in a car crash, so therefore don't bother using a seatbelt. For example, this list has a public archive with the posters e-mail addresses, so spammers can easily get them. Having a separate account for e-mail lists that deletes everything not coming from the lists is not much trouble, but it makes it a lot harder for the spammers to get your address, if it is not available anywhere on the web. Spammers also find addresses by sending out mail to common names at different domains, to see if they bounce
Re: Questions about generating keys
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Oskar L. wrote: That's good news. Can it also create them? But there are probably still many using older versions. I know some who refuse to update from 6.5.8. Yes. And yes, there are still people using the very old 6.5.8 codebase. These people ought to be dragged out into the street and forcibly introduced into the twenty-first century, but hey, that's just my opinion. Ok, so RSA isn't always significantly faster, as I thought it was. I had read somewhere that it was, (probably on this list) and my own testing with my 4GB backup files showed RSA to be notably faster. Err--how? When you're doing a signature, you're signing less than 1k of data with RSA or DSA. When you're encrypting a file, less than 1k of data is being encrypted with RSA or Elgamal. How does this test show any speed difference between the two? The time differential between RSA/DSA/Elgamal is statistical noise given the much, much larger time spent reading the 4GB of data. - for signing DSA is faster, for verification RSA is faster, but there's not much of a difference. I'd just keep the last clause. There's not much of a difference. Timing of DSA versus RSA will depend heavily on everything from processor load to disk I/O to the phase of the moon. Generally speaking, yes, the first two clauses are correct, but it's impossible to say with specificity what will happen in your particular environment. - OpenPGP implementations must support DSA, but supporting RSA is optional, but both gpg and PGP support RSA, so there's not much of a differance. Pretty much. - original DSA limited to 1024 bit keys and 160 bit hashes. Yes. - DSA signatures are smaller. Yes. - updated DSA, aka DSA2, equal to RSA when it comes to the lenghts of keys and hashes. Not really. E.g., DSA2048 uses SHA256 as a hash algorithm. But I can use SHA512 with an RSA2048 key. RSA keys offer the best selection of hash algorithms, but this is mostly a canard. - Of PGP, only the newest version support DSA2 keys. Newest versions, not version. I think PGP 9.0 introduced DSA2, and they're up to 9.5. - RSA has a hash firewall Yes, but I am unconvinced that this is something an average user needs to be concerned about. (I'm concerned about it, but I freely admit to being paranoid.) RSA still seems better to me, but not by as much as I previously thought. What does this better mean? Seriously. You're arguing about whether Godzilla or Mechagodzilla is more effective at flattening downtown Tokyo. The answer doesn't matter. Whether it's Godzilla or Mechagodzilla, people are still going to run for the hills. Likewise, given the astronomical difficulty of attacking either RSA or DSA, it's hard for me to say one is better. The instant an attacker sees RSA or DSA, the attacker is going to give up trying to forge a message by cryptanalytic means. In a lot of ways, I think this is arguing over how many angels can dance on the head of a pin. So they accepted RSA into the standard, while it was still restricted by patents, as long as it wasn't made the default? You can have a perfectly OpenPGP-conformant application that treats RSA messages as noise and silently discards them. In RFC language, there are a few special keywords that are almost always capitalized: MUST: a conformant application is required to... SHOULD: while not required for conformance, it is good if... MAY: totally irrelevant to conformance, but worth considering... NOT: invert the meaning of the preceding word. DSA is a MUST algorithm, as are SHA-1 and 3DES. RSA is a MAY algorithm. I took for granted that an open standard like OpenPGP would not have accepted any patented stuff into the standard It didn't. You can implement OpenPGP without paying anyone a dime in patent royalties. If the IETF refused to make RSA the default, does that mean that the people behind OpenPGP originally wanted it to be the default, but then had to change it to DSA? The distinction between the IETF and the people behind OpenPGP is not as big as you might think. The IETF is fundamentally composed of a lot of people who are interested in technology. That's all. Their working groups (WGs) are open to the public. Public participation on IETF mailing lists is heavily encouraged. I sit on the IETF OpenPGP mailing list just to track the latest changes. In Ye Olden Days, when Phil Z. was developing Classic PGP (PGP 2.6, RFC1991), his attitude towards intellectual property was remarkably cavalier. It created an awful lot of problems for PGP 2.6, since practically everything about it was patent-encumbered. The patent problems were one of the driving forces behind the development of a next-generation PGP technology, which became OpenPGP (RFC2440). - From the very earliest days of OpenPGP, there has been a strong commitment to the total absence of patent-encumbered algorithms from MUSTs. I would not say that just because someone
