Wind river
@rjh thanks for your earnest answer to my sloppy and somewhat provocative post. This doesn't make any sense to me. Makes perfect sense to me, once you understand three things: (a) at one point all the good crypto came out of either the US, UK, or France, I have to concede that I mostly agree with you. While i think the most dangerous current threat to our freedom and democracy is ubiquitous eavesdropping and spoofing by NSA, GCHQ and their likes, I admit US scientists also gave us the means to defend against it(strong cryptography). After reading an Scientific American Article about asymmetric cryptography by Adleman (not the original one in 1977, but a later one from the 1990ies ;-) I was fascinated. Then I heard about the issues around export restrictions and immediately sat down and coded it as an act of a physicists self respect. For me the claim to own some mathematics by an administration is pure hybris and ignorance. My little exercise didn't get any momentum back then and I ceased to pursue that any further. And yes, if you want to discuss matters of cryptography seriously, there are hardly any quality posts in german language. I have some trust in the strength of the opposition against ubiquitous government surveillance within the US and hope they will overcome current antidemocratic moves. Presumably and sadly the opposition against such tendencies is weaker in germany. If you google open source elliptic curve cryptography you will find my current activities regarding cryptography. You might notice that the softwares menus as well as the documentation is held almost completely in english language. One reason is to keep dumb german nationalistic morons off. In my opinion the current behavior of the US soup letter agencies nourishes dumb nationalistic anti-us tendencies in other countries including mine! I don't want to be forced into an alliance with nationalistic people. The US judicial system should IMHO no longer let people, who lie to congress under oath, go unharmed and pursue people, telling the truth, with all might. Please apologize me having gone somewhat off topic here (c) laws and regulations change so slowly they make glaciers look swift. agreed. Probably my (the german) administration isn't any better in this aspect. I respect you for defending your (the us) administration, yet in my opinion both our administrations deserve some bashing once in a while for excessive ignorance and/or sluggishness. Cheers, Michael Anders ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: It's time for PGP to die
Once a crisp and nicely implementable asynchronous protocol with forward secrecy comes up, however, we should have it implemented immediately.(The synchronous ones are easy, of course.) Whispersystems has done a good job with Textsecure as ar as I read the opinions about it. In practice their application is very usable too, except that MMS does not work in some circumstances (but who uses that anyway in 2014?) Think about implementing forward secrecy for a moment and imagine, you had to develop a forward secret PGP(actually in my opinion it should properly be called backward secrecy for that matter.) You have to keep track of all one to one communications with their current status of shared secrets. This is much more data to be kept secret than without fs. In fact depending on your activity possibly so much more that simply enciphering the whole database would not be efficient anymore. You would have to use a random access cipher (like e.g. in truecrypt). You dont have it yet? Then you have to code it - a formidable task- or get it from some other source. Just in case - do you trust the other source...? And if you have a random access cipher, what amount of information is visible to the intruder just from viewing the outer structure and its reaction to activity of this random access database cipher? How do you deal with simultaneously maintaining one to one communications that exchange messages 10 times a day as well as comms that talk to each other once every other year. This is a problem if you have a systen that changes public keys on a time basis. You will have to delete info regarding dead communication strands to keep the database compact. What time do you set to declare a strand dead? How do you recover if messages were lost or if a deleted strand suddenly is reanimated by your peer? How do you recover without opening a soft flank to attackers who want to highjack the strand? How do you detect it when a strand was highjacked by a MITM-Attack? How do you deal with highly asymmetric communication strands, once a year into one direction, twice a day into the other direction? How about a busy strand where one strand sends two messages in rapid succession and resets his timer in between and the messages arrive in reversed order? How do you recover in this case? How do you synchronize databases if a user wants to sustain the one to one communication using different systems(e.g. office PC - netbook-smartphone) intermittingly. I can go on and on and on. To me this IS like opening a can of worms. And I seriosly doubt if the pain is worth the reward(forward secrecy). Matthew Green mentions the Axolotl protocol and TextSecure(which you refer to in your post as well) as a product that uses it. Well if TextSecure/Axolotl -which I havent used and dont seriously know yet- solved all these problems satisfactorily and securely I bow in humble adoration(seriously). You should have a look at the Axolotl protocol https://github.com/trevp/axolotl/wiki First look at the humongous state variable! Then it takes about 60 lines of description where a standard public key protocol would take about 5. From studying the protocol, you can see that some of the above mentioned problems might be solved, yet we dont know how it stands against a brilliant attacker. The sheer complexity makes me feel very uneasy. In my view, the axolotl protocol has the elegance of transporting water in a bucket with twenty something holes, where each hole got a cork plugged into it. I wouldnt want to code it. By the way - Green (rightfully) critizises PGP for bad defaults (e.g. using SHA1) yet he praises TextSecure which heavily relies on SHA1. This leaves me baffled. Cheers, Michael Anders ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Fwd: It's time for PGP to die.
I share most of Greene's arguments agaist PGP to a limited extent, however, he seems strongly biased against it. There are two points, in which I strongly disagree with Greene: A) For me forward secrecy is not of utmost importance for asymmetric end to end mail encryption. Your private key is compromized if your system has been hacked(if you don't live in a police state where authorities can force you to reveal it). Most likely the important private messages will still reside on your system then, so they are leaked anyways in this case. So there is limited gain by implementing forward secrecy. So the complaint about lacking forward secrecy is exaggerated in my eyes. Nevertheless, there do exist solutions for asynchronous message exchange with forward secrecy and we need to have an eye on them and watch out for new publications on these. At present IMHO they are awkwardly difficult to implement and maintain and just keeping a watchful eye on them seems perfectly reasonable today. Once a crisp and nicely implementable asynchronous protocol with forward secrecy comes up, however, we should have it implemented immediately.(The synchronous ones are easy, of course.) B) A minor point. Greene complains, that in PGP securing ciphers with a MAC is not enforced in the standard. For an asymmetrically enciphered message IMHO it does not make any sense whatsoever, to secure message authenticity with a MAC. A correct MAC is proof that the message has not been altered by someone not knowing the symmetric key. But knowledge of the symmetric key doesn't prove anything since it is essentially a random number selected by the unauthenticated sender. So a correct MAC in a RSA cipher just proves that the sender is the sender - so what? (I know that many people disagree with me on this point, yet I have never heard a convincing argument for the MAC in an asymmetric cipher.) If you want authenticity, you have to have the message or cipher be digitally signed by the sender. For me the critcism of PGP is clearly unfair regarding this second aspect. Regards, Michael Anders ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Gnupg-users Digest, Vol 131, Issue 15
I'm not sure, but didn't discrete-logarithm keys scale roughly equivalently to RSA? I think so, but I'm not sure... and The guidance from NIST is: [1] shannons of entropy needed [2] bits of symmetric key [3] bits of RSA/DSA/ELG [4] bits of ECDSA/ECetc. [1] [2] [3] [4] 80 80 1024160 112 112 2048224 128 128 3072256 256 256 ~15k512 The entropy of symmetric and ECDSA/ECetc. keys scales linearly with key length; the entropy of RSA/DSA/ELG keys scales logarithmically with key length. and However, I've also been cautioned by some big names in crypto that I shouldn't put too much stock in this: we know DLP must be at least as hard as integer factorization, but we don't have precise numbers for how much harder it has to be, and the tendency over the years has been for the two to slowly converge in difficulty. As of now the best guidance is to think DLP is at least as hard as IFP, but to be skeptical about how much harder. No witchcraft, just some simple math. Baltimore published: (http://www.nsa.gov/business/programs/elliptic_curve.shtml) symm. RSA ECC 80 1024160 112 2048224 128 3072256 192 7680384 256 15360 521 The generalized number field sieve(-RSA factoring) scales with bitlength to the 1/3 (http://en.wikipedia.org/wiki/General_number_field_sieve), new improvements by Joux et al (http://eprint.iacr.org/2013/400.pdf) set it to 1/4 but this so far seems limited to smaller numbers. ECC security scales with bitlength to the 1/2 (General DLP methods) If you set the scale to 160 bit ECC being at the same security level as 1024 bit RSA (presently considered marginal security) you arrive at the formula for the generalized number field sieve: n(RSA) = ((n(ECC)^1/2)/1.25)^3 The resulting table would look like this ECC(bitlength) RSA/elGamal 160 1024 256 2072 384 3807 512 5862 768 10769 1024 16579 If you presume Joux's results would apply to RSA factoring, the formula would look like: n(RSA) = ((n(ECC)^1/2)/15.9)^4 Now the resulting table would look like this ECC(bitlength) RSA/elGamal 160 1024 256 2621 384 5898 512 10486 768 23593 1024 41943 Interestingly NIST arrives at an estimate even in excess of the second table! So we might speculate that they either know of some improvement compared to the publicly known methods to factor RSA moduli, expect such improvement from other sources or else just want to push ECC. (I like ECC - google open source elliptic curve cryptography.)) Cheers Michael Anders ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how to do
Please can you elaborate on how it is incorrect to say that somebody who knows the passphrase to a secret key can make changes to that key. Would this maybe be the case when using an encryption subkey with an offline main key? If you make encryption and signing subkeys you can export them (i.e. the secret subkeys), create a new gnupg home directory, import the subkeys, change the password on them, and finally, export and distribute them to the people who are supposed to use them. By doing this you can have a person who manages the master key separately under another password and the authorized users can use the encryption and signing secret subkeys without being able to make changes to them I think we are in danger of working with different concepts of what not being able to means. On a first level, if you have read/write access to the key-file, it is just a file and you can do pretty much anything with it. On a second level, proper cryptographic protection may prevent you from doing anything sensible with it, if you don't have access to the protecting secret(e.g.the GnuPG access passphrase). On a third level you may know the secret access key but within the small world of a particular cryto tool (GnuPG in this case) you cannot do. You may sit down and code it yourself, however. This third level of cannot do is usually disregarded by cryptographers and IT-security people, yet I think this is probably the kind of cannot do we are talking about here. I have to admit I don't know much about the way the subkey structure is organized internally in OpenPGP, so if there is some true cryptographic protection of the subkey relationships, may someone who knows about it please tell me. If there were true cryptographic protection, it would have to work without a password. This might be very interesting crypto stuff then :-).. My gut feeling makes me believe this protection is impossible with cryptographically independent keys, however, and that you could always at least embed the exported subkey into a newly created parent key structure and newly design whatever sub/super-key structure you like around the exported key. So unless there is convincing cryptographic reasoning about why you cannot do something to the key you have the access password to, I would not rely on the cannot do. Regards, Michael Anders ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Gnupg-users Digest, Vol 128, Issue 24
nt-Type: text/plain; charset=ISO-8859-1
Now where did you calculate that from?
$dS = \frac{\delta Q}{T}$
Second Law of Thermodynamics, which you just broke. Have a nice day.
The (cold) system where the calculation is done and the (hot) system the
result is transferred only exchange negligible energy and entropy.
No oceans to be boiled off.
Citing the second law of thermodynamics in this context is wrong.
Besides, just citing a physical law and selling that as reasoning is not
the way we argue in physics.
:-)
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG's vulnerability to quantum cryptography
On Wed, 2014-05-14 at 22:26 +0200, gnupg-users-requ...@gnupg.org wrote: If you want to run the temperature lower than the ambient temperature of the cosmos (3.2K), you have to add energy to run the heat pump -- and the amount of energy required to run that heat pump will bring your energy usage *above* that which you would've had if you'd just run it in deep space at 3.2K. Now where did you calculate that from? In fact arriving at a realistic estimate for the energy needed to brute force AES is really hard work. (Besides: Who can say for sure that we cannot get some bits from cryptoanalytic progress(two bits already crumbled). The cracking of DES was indeed a combination of analyzing some bits and the finishing up the rest by brute force.) IMHO you can run the calculations entirely at low temperature, whatever technology you use to get there. Then you only need contact to the warm world once to transmit the result(for negligible effort!). Look at it this way: A hypothetical nuclear organism in the sun might communicate with us about a result we calculate for it in order to crack some stellar cryptosystem. This doesn't force us to heat our computers to 1 K and burn all this energy needed for calculating at high temperature. We could e.g. communicate the result to that being via pulsed gamma rays These discussions tend to get an interesting quasi-religious setting: 1.) We don't have anything other than AES (At least many people think so.) so one type of character says: We don't have anything else so it must be safe and we must defend that conviction against heresy. the other type (me) is equally mazed and says: They don't want to give us anything else, so it must be unsafe. Relying on them is heresy... May be I should switch sides entirely and go with the very practical asbestos longjohns. I really like the picture :-) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GPG's vulnerability to quantum cryptography
GPG encrypted data (using RSA) can be collected today and easily decrypted after 50-100 years using a quantum computer. See: https://en.wikipedia.org/wiki/Shor%27s_algorithm Well let's see. Usually in a new technology, once you are really going to apply it in the real world, new problems not thought of before are going to pop up. (Think of fusion energy from the tokamak, which is always predicted to be here in 20 years from now - since more than 40 years.) For this reason, what I do today is share long keys with people I know *in person*. We then use regular AES-256 to encrypt/decrypt our messages back and forth. Every 6 months we meet in person to renew our keys. (To be more secure, we actually create the keys in portions via in-person at different places, OTR, SMS, landline phone, mobile phone, and snail mail.) AES-256 is not vulnerable to quantum cryptography as RSA is, so we feel much safer this way. There is another quantum algorithm called Grovers Algorithm that would reduce the effort to crack 256 bit key AES to the effort necessary to crack 128 bit key AES. Since the well known agency from Baltimore uses its influence to have crypto standards coast close to the limit of the brute-forceable, 128 bit AES will be insecure not too far in the future. So if you are worried about the quantum computer, using AES as is directly won't help you a lot. You'd also need symmetric algorithms with at least 512 bit keys and at least 256 bit block size to retain the same security margin as in the pre quantum computer era. Large block and key size algorithms surely do exist. 50 years from now, I'm going to be 105. So if I 'll be alive then, I'll be grateful to be able to ask quantum computer equipped Baltimore for help on recovering my old secrets which might have slipped from my memory by then ;-) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Multiple Subkey Pairs
I apologize for having triggered the emotionally agitated exchange in this thread culminating in someone bringing up the German-Jew trauma. I did not intend this and will try to make future points in a more moderate language. I acknowledge the outburst of true emotion by the person I responded to initially. Unfortunately my initial contribution was held for moderation and finally has been withheld for reasons unknown to me. All that was left is a belated, empty response under my name in the last digest. Since followers of this discussion cannot possibly understand the heated responses without the trigger, I'll try it again. Hopefully this will end the emotional part and will get the discussion back onto the appropriate technical track. This time I'll slightly redact my initial contribution so as to avoid it being held by a moderator. Here we go -Quote: So far there's no credible reporting that any government is doing mass surveillance of email content. Instead, mass surveillance focuses on metadata: who's talking to whom, when, with what for a subject line, routed through which mail servers, and so on. The YYY (-a famous three letter agency) e.g. denies to archive content of YYY citizens mails. It is thus perfectly reasonable to assume it does so with all other ones. They can easily do it, thus they do it. I am german, so I am free game for them anyways. Besides, you believe their denials - are you kidding? GnuPG does not and cannot protect against that. This is as regrettable as it is true. Worse still, it is much more cumbersome to protect your metadata than to protect content with e.g. GnuPG. You could achieve it easiest with Y(-We all would know how to do this). A public key infrastructure is difficult to reconcile with anonymity. If your concern is mass surveillance -- which is to say, metadata -- sorry again, if we are speaking about the YYY, only metadata if recipient and sender are YYY citizens and if we believe what the agency says. Regarding the the security of the content, I share the view that lighting a firework of a dynamic subkey structure is not going to help. IMHO one properly kept key is enough and its security should last for decades. After all the all or nothing principle is at the core of cryptography in many contexts. There is no such thing as attrition of security by heavy usage of a public RSA or ECC key. When it comes to system compromise leading to broken security. This is not kind of an aging process smoothly proceeding with time and eventually leading to death. They target you or they don't. cheers Michael Anders (a reference to my project page) *** End of quote. The reference to my crypto project homepage which also contains a political statement, might also have been the problem. Those who are interested and dont't feel offended by a positive reference to a controversial person can find it via my homepage www.fh-wedel.de/~an/ following the link to Academic Signature. Best regards, Michael Anders ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Multiple Subkey Pairs
So far theres no credible reporting that any government is doing mass surveillance of email content. Instead, mass surveillance focuses on metadata: whos talking to whom, when, with what for a subject line, routed through which mail servers, and so on. The NSA e.g. denies to archive content of us-american citizens mails. It is thus perfectly reasonable to assume it does so with all other ones. They can easily do it, thus they do it. I am german, so I am free game for them anyways. Besides, you believe their denials - are you kidding? GnuPG does not and cannot protect against that. This is as regrettable as it is true. Worse still, it is much more cumbersome to protect your metadata than to protect content with e.g. GnuPG. You could achieve it easiest with temporary anonymous e-mail accounts. A public key infrastructure is difficult to reconcile with anonymity. If your concern is mass surveillance -- which is to say, metadata -- sorry again, if we are speaking about the US, only metadata if recipient and sender are us citizens and if we believe what the agency says. Regarding the the security of the content, I share the view that lighting a firework of a dynamic subkey structure is not going to help. IMHO one properly kept key is enough and its security should last for decades. After all the all or nothing principle is at the core of cryptography in many contexts. There is no such thing as attrition of security by heavy usage of a public RSA or ECC key. When it comes to system compromise leading to broken security. This is not kind of an aging process smoothly proceeding with time and eventually leading to death. They target you or they dont. cheers Michael Anders (http://www.fh-wedel.de/~an/crypto/Academic_signature_eng.html) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Encrypting File with passphrase,
Hi Vikash On Thu, 2014-03-13 at 10:36 +0100, gnupg-users-requ...@gnupg.org wrote: Encrypting File with passphrase Now I am trying to encrypt the file on server B using this public key, I am able to do so without any matter I pass the passphrase or not. So my ask is, if a key pair is generated with passphrase it won't restrict the encryption incase incorrect passphrase or no passphrase is passed? Also I was able to encrypt the file on server B by providing any random passphrase, but decryption is possible with correct passphrase only. You do not need a passpharase for operations with a public key (encryption or signature verification) because the key is not secret. Everyone is allowed to access it, so there is no need to protect it with a passphrase. This is the essence of asymmetric cryptography. Apparently Gnupg just ignores a password given when it is not needed. This seems reasonable to me. regards Michael Anders (http://www.fh-wedel.de/~an/) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key generation: paranoia mode - explicit random input
The discussion on what to do in a partially compromized system is IMHO irrelevant. If a private key has been accessed on a system some adversary might have had a chance to tamper with(e.g. with the PRNG or generally if it is an NSA friendly OS connected to the web ;-) , there could have been a keylogger in place and security of the key is gone. If you consider the NSA to be a benevolent organization, you might make a distinction between security against criminals and security against the NSA, but that is politics and not cryptography. Cheers, Michael Anders ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Trying to understand the bond between master and subordinal key pairs
On Wed, 2014-02-12 at 11:38 +0100, gnupg-users-requ...@gnupg.org wrote: Am Mi 12.02.2014, 07:02:51 schrieb Faru Guredo: This is suggested???as far as I understand???in order to keep the original master key for signing in a secret place, because master signing key = my genuine identity. But. Signing (data) is not the relevant aspect of a mainkey. Certification (i.e. signing key components) is. You can create mainkeys which are not capable (i.e: not allowed) of signing data at all. Which public keys should be uploaded to the keyserver? All public keys must be available to the public. (You cannot even prevent that from happening.) The public mainkey is necessary for the verification that the subkeys belong to this mainkey. Furthermore it is needed for the fingerprint check. But what about gathering signatures of other people on your own public key? Should I upload public key of my master signing key along with the public key of the subordinate keypair I am planning to use daily? These two components are not related at all. These should be two distinct questions. I don?t get the bond between master keys and subordinate keys. Does it even exist? The mainkey binds the subkeys by signing them. Signature subkeys have to sign the mainkey, too, in order to become valid. OpenPGP considers signatures by a subkey as equivalent to those by a mainkey. But if everyone understand what this means (and how it can be checked) then you can use the protected mainkey for more secure signatures (if you do not have a more secure other key). You can use it for more secure encryption, too (again: If everyone involved understands how to do that). To me they look like totally different keys. They are, technically. They could even be exchanged. But the OpenPGP key format marks one as the mainkey and the other ones as subkeys. Okay, when I usually sign files with key when I send them to Alice, and eventually I want to sign her key (?which of her keys, actually? The one she uses daily or the one she keeps like me? If she keeps it, how did it get to me? Which public keys supposed to collect signatures of other people ??of the master one or newly created subordinate one?), I need to use my master key . How does she know that is also my key if they have different IDs? That's not the way keys are used. You tell the application to use the key 0x. That always refers to a mainkey. The OpenPGP subsystem (GnuPG) then selects the appropriate key: either the mainkey of a subkey. Your contacts only verify 0x. Possible subkeys are verified automatically (you cannot prevent that). Signatures are shown to be made by the mainkey. More precise: GnuPG does show you the subkey which made the signature but I don't believe any GUI does (in a way useful to beginners). You can even force GnuPG to use a certain subkey (if technically possible) or the mainkey and thus override the automatic selection. But I have never seen a higer-level application offering that. (Let?s assume public key of the master pair is irrelevant, That is not a useful assumption. I kept wondering about this too. Thanks a lot for the explanation of how it works. I am still puzzled, however. Can anyone explain the logical reason as to why we need this jungle in OpenPGP, which thankworthily is usually more or less hidden from the user anyways? A good reason would help the complicated workings to stick with my memory :-) Why would we need more than one key and this hierarchy on top of it? (Proper padding according to the standard to my knowledge removes even the dangers of using the same RSA key for signatures as well as for ciphers.) Is the necessity(given that it is there) for the subkey hierarchy endemic to RSA or would such a structure also be needed for ECC or other cryptosystems? Cheers, Michael Anders ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Subject: openpgp card and basiccard RNG
Hello, Aparrently the OpenPGP card is based on BasicCard [1] and from the BasicCard FAQ [2] I read: For Enhanced BasicCards, the card has no hardware generator. The Enhanced BasicCards contain a unique manufacturing number which cannot be read from outside the card. The Rnd function uses this number to generate random numbers which are different for each card. For Professional and MultiApplication BasicCards, the random number is generated by use of a hardware random number generator. Does anybody know which version of BasicCard is used for the OpenPGP cards distributed by KernelConcepts.de? If it is the Enhanced version, does the use of a pseudorandom generator pose a security risk? In my opinion a (good) PRNG seeded properly under user control is no problem. If -as the FAQ seems to tell- it is primed during production, beyond user control, this implies that normal users have to fully trust the manufacturer. A malicious manufacturer would be able to completely break privacy based on the Enhanced BasicCard without the user being able to detect this. An instance is created here, deliberately and unnecessarily, which the user has to trust. This pattern smells like a backdoor mechanism to me. I would outrighly reject to use such a card. Cheers Michael Anders ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
cryptanalysis question: Does knowing some of the content of the message make the full message vulnerable to decryption?
Short answer: No. This would be a form of a (partially) known plaintext attack. Semantically secure ciphers are safe against this attack and it is not possible to extract information on the key. To be precise, you may of course be able guess a lot in the plaintext domain: Edward Snowden is a %@ยต does leak further information and could easily be fully deciphered. But this has nothing to do with cryptography. However, in plain CBC ore counter mode(CTR) for the symmetric encryption it would be possible to change the blocks of known content against content of your liking. This is especially easy and undetectable to the recipient for CTR-mode(just XOR it out). In CBC mode it is more complicated and you would usually mess up some other parts of the decrypted message to unreadable gobbledonk. That is why you need special provisions to protect the authenticity of the cipher in transit if you are using symmetric cryptography only. In this case knowledge of the shared symmetric key is sort of proof that you are a legitimate sender. I don't know how gpg does it, in academic signature I use an hmac to protect solely symmetrically enciphered messages. There are standardized modes you might use to achieve that e.g. EAX or CCM. In an asymmetrically enciphered message it makes sense only to use digital signatures to protect the message or cipher(as opposed to the EAX, CCM or other symmetrically authenticated modes). Here the symmetric key is created on the fly for just this message and knowledge of the symmetric key alone would be no proof of anything other than that the sender is the sender. If you have a shaky system that might get disrupted by feeding it maliciously crafted information, it would make sense to asymmetrically sign the cipher and only decrypt if the signature is valid. Generally it is logically more sound to sign the content and then symmetrically encipher content and signature. Again I don't know how gpg does it. May be someone knowing the gpg internals might supply the information. Some people may disagree on the content of this last paragraph regarding usefullness of authenticated symmetric encryption in combination with asymmetric cryptography. There is even a proposed standard ECIES which combines asymmetric cryptography with symmetrically authenticated ciphers. I do not consider ECIES to be logically sound. If you are interested in this topic, you may have fun listening into Dan Bonehs great lectures on cryptography in coursera (for free). https://www.coursera.org/courses?orderby=upcomingsearch=cryptography regards Michael Anders ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Any way for two correspondents to set up gnupg within a few moments without having to become expert?
Any way for two correspondents to set up gnupg within a few moments without having to become expert? The usual gnupg materials are very dense. Ask an expert to do the setup. After that usage is simple. In my opinion public license software is about empowering people. If you need an expert to install a software for you, the dependency on a software vendor is replaced by the dependency on an expert, which might be even worse in some circumstances. Experts should also see their role in empowering people. Yes, there is a necessity to have good GUI based installers that don't need an experts assistance to get things right (and eventually change the insecure gpg defaults for that matter...) gpg4win works just fine.(So does Truecrypt or Academic Signature if you look at other crypto) The users must invest some minutes in understanding what asymmetric cryptography is about, however. That should be well within the scope of people with normal intelligence. Without that very basic understanding, using GnuPG(or other public key crypto) would be reckless nonsense anyways. Becoming a console wizard should definitely not be necessary. Regards Michael Anders ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Any way for two correspondents to set up gnupg within a few moments without having to become expert?
You mean what you personally consider insecure defaults. Please let's not confuse people by stating opinions as facts. You're entitled to your opinion, though. HTH, Peter. My opinion is that SHA1 should no longer be used. A link on SHA1 security: https://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html regards, Michael Anders ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Any way for two correspondents to set up gnupg within a few moments without having to become expert?
On Tue, 2014-01-21 at 14:19 +, Steve Jones wrote: How do I prevent gnupg from using SHA1? Also how do I update my key to not use SHA1 digests which it appears to be using, as well as listing SHA1 as my second favourite algorithm. I found a description in the web( http://sparkslinux.wordpress.com/2013/02/21/hashing-algorithm-is-your-gpg-configuration-secure/) that told me to do the following: You locate the file gpg.conf On my ubuntu it is in the directory ~/.gnupg/ In this file you can add the three lines at the bottom personal-cipher-preferences AES256 TWOFISH AES192 AES personal-digest-preferences SHA512 SHA384 SHA256 personal-compress-preferences ZLIB BZIP2 ZIP to set the preferences. GnuPG is supposed to pick the leftmost possible in the respective lists. But backup before editing! I remember some recent posts on problems editing GnuPG config files and tranferring to and fro windows and linux. There seems to be a danger to mess up things using wrong editor settings. I don't know if hash preference information is additionally attached to keys. I would guess it is not, it wouldn't make sense to me. regards, Michael Anders ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
for GnuPG GUI, force gpg response in english language?
I am maintaining a program that features a minimalistic GnuPG GUI as an accessory. (http://www.fh-wedel.de/~an/crypto/Academic_signature_eng.html) Now I encountered a problem with other than english versions of GnuPG: a) The verification of a signature (--verify) always returns false, regardless of the result of the verification.(May be someone can give me a rationale for this behavior.) b) as a workaround I have my interface analyze the comments gnupg returns. It so happens that the comments on --verify are returned in the error channel. So I checked for the keyword good signature in the error channel to use it as a flag that verfication succeeded. That works nicely. When I install my software on a german language ubuntu, however, the response is given in german language and is not good signature but a german tranlation. The GUI obviously fails to recognize the success of the verification then. I presume you can see it would be awkward to check for good signature in all languages from afrikaans to zulu. A GnuPG option to force the response to be in english would solve the problem elegantly. Can anyone give me a hint on how to do that? I wish you all had a Merry Christmas and will have a Happy New Year, Michael Anders ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ECC curves used in gnupg?
On Tue, 2013-12-17 at 13:01 -0600, Anthony Papillion wrote: I know that gnupg is experimenting with ECC and I'm wondering which curves the team has decided to use. I know there are some curves that are now suspected of being tainted by the NSA through NIST. Has the gnupg team ruled using those curves out? Wouldn't it be nice to include ecc curves up to 1024 bit(ecc brainpool gives you 512 bit at most, maryland 521). I calculated the parameters last year(no ties to maryland) and they are free for noncommercial use ;-) They can be found here: http://www.fh-wedel.de/~an/crypto/accessories/domains_anders.html In the ECC software Academic Signature -which contains a minimalistic GnuPG GUI by the way- you can check their sanity, including the MOV condition. There has been a thread on insecure GnuPG defaults lately. (SHA1 h) Please keep in mind that (to my knowledge) maryland does allow the export of ecc software up to 256 bit if in the interest of national security. So why not exclude bit sizes smaller than 256 from the very beginning. regards Michael ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
