Re: [tor-talk] BitMail.sf.net v 0.6 - Secure Encrypting Email Client
On Tue, Nov 5, 2013 at 2:38 AM, rw...@countermail.com wrote: Hello, can BitMail.sf.net as a p2p email tool for encrypted Email (and hybrid with IMAP-Email) be regarded as a reference model for research to create a secure Email Client? as it uses both, gnupg and openssl! http://bitmail.sourceforge.net/ https://sourceforge.net/projects/bitmail/files/BitMail_0.6_2088RC1/ Does anyone know, if it runs over Tor? Sincerely, Robert So... 'Robert', who do you work for? NSA? Financial crime? I mean, with the net moving to encrypt everything we'd expect to see many new and unknown yet seemingly polished tools being dropped on unsuspecting first time users just to collect their key material. Surely someone will have fun with your windows binaries. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Proof of possession when exchanging keys
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I seem to recall reading somewhere that when exchanging keys in person, you should not only have the person verify the key fingerprint, but you should also present them with 1) an unpredictable challenge document to sign or 2) verify that they can decrypt an encrypted message using the key in question. This would ensure they have access to the secret half of the keypair in question. Is verifying proof of possession necessary or good practice, or is checking fingerprints (and, when you don't know the person, photo ID or similar) enough? Phil -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Darwin) iQIcBAEBAgAGBQJSg62LAAoJEDe3IfDa5pYf6jwP/ApNoDfMbn3RtF8m494BAOFj 4S1EcJD+hn0nIhwABsZSpR3JsIFdK+5Sc4LDT2RnEmBhvo21Bn6l1W8GyCmbKqbA GOSPNBdSWLmnyNMQfOQ4pzKIyexs0qM610BG81pZaIEiDPTpNJxkZt1Uu4/Xlfvo mVnxf06tfp7h4ue04gznrKpAAKWPO7OG9XukCe93QxuOuP9L7B83jYQsg/wMBaFS x3smYgHfM8wrm4tsenbmnq8rCAMrZunl9n/BERjITcjQSPD8vZY5Ko81YyW47Fel qyiIVVJR6/xW0+LHLn3dx5Uyj3Da/vdfK43GKc5YDp76XdrMkk1Ts/KobfmgilGI WuWZesFlKb5zij93rKCIiEoKxkDnX3QvfgertXeHxZwsnEdxJyEtoGHDgb3lV0Gl jgaw/iWdJ9cJJIT8tIhvl6SMLV0Wa61OSjDk5XvfppFKU7WncqRn4UGjJKR1Q+9P ik7q2eyG6TjqtW3FTLCO165q/QF2BvWGDvoHqcymaw3Q1SzKKZ/Kq5L7kAc9UGXZ diZ3NOCZfPf608fqFF37zgZZlNVsbkThQcN4xhjqBoxeqch/0quvRXM/nWBnTXAk HDHe2DW3vy+BJ7wT1JKyAPKr19LNKvNlKi5og/4/3+FfVFELisgphUY+kf0m2Ops GzTfJIrwHTmwatg8rS4+ =4ll+ -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [tor-talk] BitMail.sf.net v 0.6 - Secure Encrypting Email Client
At 09:04 PM 11/13/2013, grarpamp wrote: On Tue, Nov 5, 2013 at 2:38 AM, rw...@countermail.com wrote: Hello, can BitMail.sf.net as a p2p email tool for encrypted Email (and hybrid with IMAP-Email) be regarded as a reference model for research to create a secure Email Client? as it uses both, gnupg and openssl! http://bitmail.sourceforge.net/ https://sourceforge.net/projects/bitmail/files/BitMail_0.6_2088RC1/ Does anyone know, if it runs over Tor? Sincerely, Robert So... 'Robert', who do you work for? NSA? Financial crime? I mean, with the net moving to encrypt everything we'd expect to see many new and unknown yet seemingly polished tools being dropped on unsuspecting first time users just to collect their key material. Surely someone will have fun with your windows binaries. Hmm, lots of lists I'm not subscribed to on the To: line, bad juju on someone's part for the initial crosspost. Hopefully, those other list maintainers will see and approve my comment, even though I'm not subscribed to all those other lists: I'm replying because, Sourceforge? They fell out of vogue when they started bundling binary downloads with other executables, they deserve to die a quick death for that as users flock to safer environs. 'Robert' should upload his binaries to Github. Along with his source code. Then, if the MD5 checksum on his compiled binaries matches the MD5 checksum on the source code when it is compiled independently, he's golden. That is how that works, how it is supposed to work. Accept no substitutes. -- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
ENISA Recommendation for Crypto processes
Heise security news published an article ENISA-Empfehlungen zu Krypto-Verfahren (ENISA Recommendation for Crypto processes). The article is in German language and can be found under http://heise.de/-2043356. It holds a summary of the latest recommendations of ENISA, the European Union Agency for Network and Information Security (http://www.enisa.europa.eu/). For those not reading German the summary of the summary report is: Symmetric 80 bit keys are accepted for transaction data and existing systems to be replaced in the next 5 -10 years. Symmetric keys of 128 bit are OK for mid-term and 256 bit for long-term use. * Cryptographic Primitives * Block Cipher - AES 128, long-term AES 256 bit Hash Function - SHA-256, long-term SHA-512 (Camellia, SHA-3 and Whirlpool are discussed) Stream Ciphers - Rabbit + Snow 3G (RC4 to be removed) * Public Keys* Elliptic Curve Cryptography is recommended: Transactions - 160 bit, mid-term storage - 256 bit, long-term storage - 512 bit RSA still can be used, recommendations are: legacy systems only - key size smaller than 3072, mid-term storage - minimum 3072 (!), long-term storage - 15360 (corresponds to 256 bit key symmetric encryption) * Protocols * Some detailed recommendations are made for protocols as TLS (Camellia_128_GCM_SHA256, AES_128_GCM_SHA256), SSH (inter alia aes128-ctr with hmac-sha2-256) Kerberos and IPSEC. The original ENISA article Recommended cryptographic measures - Securing personal data is available under http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report. flame on Regards Juergen Polster 0xA3FCFD07 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Proof of possession when exchanging keys
The general practice I follow is to verify fingerprint and ID separately then, in order to verify control of email address and private key, send the signed ID encrypted to the provided email address. On Wed, Nov 13, 2013 at 11:49 AM, Phil Calvin p...@philcalvin.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I seem to recall reading somewhere that when exchanging keys in person, you should not only have the person verify the key fingerprint, but you should also present them with 1) an unpredictable challenge document to sign or 2) verify that they can decrypt an encrypted message using the key in question. This would ensure they have access to the secret half of the keypair in question. Is verifying proof of possession necessary or good practice, or is checking fingerprints (and, when you don't know the person, photo ID or similar) enough? Phil -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Darwin) iQIcBAEBAgAGBQJSg62LAAoJEDe3IfDa5pYf6jwP/ApNoDfMbn3RtF8m494BAOFj 4S1EcJD+hn0nIhwABsZSpR3JsIFdK+5Sc4LDT2RnEmBhvo21Bn6l1W8GyCmbKqbA GOSPNBdSWLmnyNMQfOQ4pzKIyexs0qM610BG81pZaIEiDPTpNJxkZt1Uu4/Xlfvo mVnxf06tfp7h4ue04gznrKpAAKWPO7OG9XukCe93QxuOuP9L7B83jYQsg/wMBaFS x3smYgHfM8wrm4tsenbmnq8rCAMrZunl9n/BERjITcjQSPD8vZY5Ko81YyW47Fel qyiIVVJR6/xW0+LHLn3dx5Uyj3Da/vdfK43GKc5YDp76XdrMkk1Ts/KobfmgilGI WuWZesFlKb5zij93rKCIiEoKxkDnX3QvfgertXeHxZwsnEdxJyEtoGHDgb3lV0Gl jgaw/iWdJ9cJJIT8tIhvl6SMLV0Wa61OSjDk5XvfppFKU7WncqRn4UGjJKR1Q+9P ik7q2eyG6TjqtW3FTLCO165q/QF2BvWGDvoHqcymaw3Q1SzKKZ/Kq5L7kAc9UGXZ diZ3NOCZfPf608fqFF37zgZZlNVsbkThQcN4xhjqBoxeqch/0quvRXM/nWBnTXAk HDHe2DW3vy+BJ7wT1JKyAPKr19LNKvNlKi5og/4/3+FfVFELisgphUY+kf0m2Ops GzTfJIrwHTmwatg8rS4+ =4ll+ -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Thomas Harning Jr. (http://about.me/harningt) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [tor-talk] BitMail.sf.net v 0.6 - Secure Encrypting Email Client
So... 'Robert', who do you work for? NSA? Financial crime? FBI, actually, in counterintelligence. No, wait, whoops, wrong Robert Hanssen. Sorry, I get confused about myself sometimes. All kidding aside, we don't need to cast aspersions on the motives of people who post here. It is far, far more likely that someone is innocently unwise about something than that someone is being deliberately malicious. I mean, with the net moving to encrypt everything we'd expect to see many new and unknown yet seemingly polished tools being dropped on unsuspecting first time users just to collect their key material. And this is, frankly, just paranoia. New and unknown yet seemingly polished tools have *always* been dropped on the computing community. Always. I remember a really neatly polished Mac OS file encryption program that conveniently put the decryption key as plaintext in the first few bytes of the output. Making a beautiful-looking user interface is easy. Making rock-solid crypto is hard. Those two facts by themselves mean there will always be an abundance of beautiful-looking bad systems, and always a shortage of primitive-looking solid systems. Let's remember that this list is a community. Let's not malign other people's motives, and let's keep a sense of perspective about things, okay? :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [tor-talk] BitMail.sf.net v 0.6 - Secure Encrypting Email Client
I'm replying because, Sourceforge? They fell out of vogue... For a service that's out of vogue they still host an awful lot of Free Software, and for that I think perhaps we should be a bit thankful. Their bundling is distasteful, yes, but it's hardly the end of the world given they've only done it with the explicit permission of the projects involved. Let's keep a sense of perspective and remember this is GnuPG-Users, not a Sourceforge list. 'Robert' should upload his binaries to Github. Whenever I hear someone say what another developer 'should' do, I always mentally substitute 'I want this developer to...' instead. That seems quite a lot more honest. That said, there are two major problems with this demand: * The 'Robert' who asked about BitMail never claimed to be the author and may not have the legal right to host the binaries * GitHub hasn't allowed projects to host binary files in well over a year. So yes, there are good legal and technical reasons why your demand cannot be complied with. if the MD5 checksum on his compiled binaries matches the MD5 checksum on the source code when it is compiled independently, he's golden. That is how that works, how it is supposed to work. Accept no substitutes. Goes against current US-CERT guidance, which deprecates MD5 for all purposes. The newer SHAs are the way to go. Further, getting two computers to generate the exact same binary code from the exact same source code is a surprisingly difficult challenge. It requires a perfect match of everything from compiler versions to C library versions right down to identical *clocks* -- because often, compilers will incorporate timestamps into the output. Doing checksum validation of source code is feasible. Of binary code, not really. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
reproducible builds [was: Re: BitMail.sf.net v 0.6 - Secure Encrypting Email Client]
On 11/15/2013 12:06 PM, Robert J. Hansen wrote: getting two computers to generate the exact same binary code from the exact same source code is a surprisingly difficult challenge. It requires a perfect match of everything from compiler versions to C library versions right down to identical *clocks* -- because often, compilers will incorporate timestamps into the output. Doing checksum validation of source code is feasible. Of binary code, not really. Robert's right that reproducible binary builds are a non-trivial task. However, they're not impossible, and this is an active and ongoing field of work. For those interested, i recommend this as a jumping off point: https://wiki.debian.org/ReproducibleBuilds#References Regards, --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
ENISA Recommendation for Crypto processes
Heise security news published an article ENISA-Empfehlungen zu Krypto-Verfahren (ENISA Recommendation for Crypto processes). The article is in German language and can be found under http://heise.de/-2043356. It holds a summary of the latest recommendations of ENISA, the European Union Agency for Network and Information Security (http://www.enisa.europa.eu/). For those not reading German the summary of the summary report is: Symmetric 80 bit keys are accepted for transaction data and existing systems to be replaced in the next 5 -10 years. Symmetric keys of 128 bit are OK for mid-term and 256 bit for long-term use. * Cryptographic Primitives * Block Cipher - AES 128, long-term AES 256 bit Hash Function - SHA-256, long-term SHA-512 (Camellia, SHA-3 and Whirlpool are discussed) Stream Ciphers - Rabbit + Snow 3G (RC4 to be removed) * Public Keys* Elliptic Curve Cryptography is recommended: Transactions - 160 bit, mid-term storage - 256 bit, long-term storage - 512 bit RSA still can be used, recommendations are: legacy systems only - key size smaller than 3072, mid-term storage - minimum 3072 (!), long-term storage - 15360 (corresponds to 256 bit key symmetric encryption) * Protocols * Some detailed recommendations are made for protocols as TLS (Camellia_128_GCM_SHA256, AES_128_GCM_SHA256), SSH (inter alia aes128-ctr with hmac-sha2-256) Kerberos and IPSEC. The original ENISA article Recommended cryptographic measures - Securing personal data is available under http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report. flame on Regards Juergen Polster 0xA3FCFD07 PS: I send this twice as it seems that the first one did not make it. In case it comes double I already apologize :-) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Implementation idea of CURVE25519 for gnupg 2.1
Hi, There is GPL 3 based implementation of CURVE25519 called Pretty Curved Privacy (pcp1). http://www.daemon.de/PrettyCurvedPrivacy What do you think about using parts of the ppc1 source code to implement such functionality into gnupg 2.1? http://www.daemon.de/idisk/Apps/PrettyCurvedPrivacy/pretty-curved-privacy-0.1.4.tag.gz Myself I like this SCII Case Demo video how to use this utility: http://asciinema.org/a/6135 Short description (from the website): # --- Pretty Curved Privacy (pcp1) is a commandline utility which can be used to encrypt files. pcp1 uses eliptc curve cryptography for encryption (CURVE25519 by Dan J. Bernstein). While CURVE25519 is no worldwide accepted standard it hasn't been compromised by the NSA - which might be better, depending on your point of view. Caution: since CURVE25519 is no accepted standard, pcp1 has to be considered as experimental software. In fact, I wrote it just to learn about the curve and see how it works. Beside some differences it works like GNUPG. So, if you already know how to use gpg, you'll feel almost home. # --- Kind regards, Mark -- m...@it-infrastrukturen.org http://rsync.it-infrastrukturen.org ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Implementation idea of CURVE25519 for gnupg 2.1
On Friday 15 November 2013 21:33:08 Mark Schneider wrote: Hi, There is GPL 3 based implementation of CURVE25519 called Pretty Curved Privacy (pcp1). http://www.daemon.de/PrettyCurvedPrivacy What do you think about using parts of the ppc1 source code to implement such functionality into gnupg 2.1? FYi: Werner already implemented Ed25519 (based on Curve25519, but with a different signature algorithm) in GnuPG: http://www.ietf.org/mail-archive/web/openpgp/current/msg07194.html Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Proof of possession when exchanging keys
On Friday 15 November 2013 11:39:30 Phil Calvin wrote: On Nov 15, 2013, at 11:02, Thomas Harning Jr. harni...@gmail.com wrote: The general practice I follow is to verify fingerprint and ID separately then, in order to verify control of email address and private key, send the signed ID encrypted to the provided email address. That makes perfect sense. That's the approach I took on the most recent key I signed. What attacks are mitigated by verifying control of the secret key, though? I am having a hard time grokking the benefit for someone whose ID you have verified to present and fingerprint a key which she does not control. By signing the UIDs connected to a key you certify that the UIDs (most commonly email addresses) belong to the same person. You and people trusting your certifications could be lead into sending an encrypted message meant for the owner of an email address not belonging to the key owner to one of the email addresses of the key owner. It may seem a bit far-fetched that somebody would use one of the email addresses of the key owner instead of the email address of the intended recipient, but a possible reason for this could be that the email address of the intended recipient stopped working (e.g. because he changed his ISP or his employer). Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ENISA Recommendation for Crypto processes
Am Fr 15.11.2013, 15:40:30 schrieb Juergen Polster: For those not reading German the summary of the summary report is: Symmetric 80 bit keys are accepted for transaction data and existing systems to be replaced in the next 5 -10 years. Symmetric keys of 128 bit are OK for mid-term and 256 bit for long-term use. * Cryptographic Primitives * Block Cipher - AES 128, long-term AES 256 bit Hash Function - SHA-256, long-term SHA-512 (Camellia, SHA-3 and Whirlpool are discussed) Stream Ciphers - Rabbit + Snow 3G (RC4 to be removed) * Public Keys* Elliptic Curve Cryptography is recommended: Transactions - 160 bit, mid-term storage - 256 bit, long-term storage - 512 bit RSA still can be used, recommendations are: legacy systems only - key size smaller than 3072, mid-term storage - minimum 3072 (!), long-term storage - 15360 (corresponds to 256 bit key symmetric encryption) That is a strange paper. The text is not even consistent: We have focused on 128 bit security in this document for future use recommendations; clearly this offers a good long term security gaurantee. It is plausible that a similar recommendation could be made at (say) the 112 bit security level (which would correspond to roughly 2048 bit RSA keys). The line has to be drawn somewhere and there is general agreement this should be above the 100-bit level; whether one selects 112 bits or 128 bits as the correct level is a matter of taste. Due to the need to protect long term data we have taken the conservative choice and settled on 128 bits; with a higher level for very long term use. Thus in recommending key sizes we make two distinct cases for schemes relevant for future use. The first cases is for security which you want to ensure for at least ten years (which we call near term), and secondly for security for thirty to fifty years (which we call long term). For near term use we recommend AES-128 and for long term use AES-256. Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/bekannte/ OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
