Re: encrypting to expired certificates
This is a resent because I accidentally mailed Peter Lebbing directly without the mailing list. Allow me to lay to rest all the confusion in this thread. On Tue, Sep 16, 2014 at 6:45 AM, Peter Lebbing pe...@digitalbrains.com wrote: I wanted to encrypt a document to myself on an offline system[1]. However, that copy of my own key was expired, and it wouldn't do it. I was in a bit of a hurry, trying to get things done. Now, I had to get a USB drive, start another computer, export my updated key, and import it on the offline system. If I had --expert followed by yes to an Are you sure? prompt, I would have done that and updated the copy when I had more time. Not really sure where you're going with this. It has already been *established* that if you're the key owner you can adjust the expiration date of the key. I think there's a lot of confusion around the intention of a floating expiration here. Expiring keys have the following function: Expiring local copies of public keys on other peoples' computers to force them to get a public key update from the owner. That is to say that if I have Peter Lebbing's public key and it has expired that means I must reach out to Peter Lebbing for the latest copy of the public key of the exact same fingerprint. Expiration in this context does not mean the key is forever invalid. It means that *my copy* is invalid until I get a more recent update from Peter Lebbing. That just means Peter Lebbing would have changed the expiration date of his public key and extended it. So when I get his new expiration date that is the time in which I must reach out to him next for another public key update of the same finger print. This protects both the key owner and correspondent in a couple ways. 1) If I have an expired key and I check to see what the latest key is of Peter Lebbing, he may have revoked it. In this case it forced me to go out and check and see that it was revoked so I *must* not use this key again. He can give me his new key with proper WoT validation. 2) If Peter Lebbing as a key owner loses his key and my local public key of Peter Lebbing expires then the next time I reach out to Peter Lebbing for the latest key copy he can tell me he, in fact, lost the key and give me a new one with proper WoT validation. To bring this full circle: the expiration date's purpose is to force users of any public key to periodically check with the key owner that the public key is still valid. RESOLUTION So if a key is expired I *must* not encrypt with it. I *should* instead reach out to the key owner and ask for their latest public key of the same fingerprint which would have a new adjusted expiration date. This ensures I'm not encrypting to a compromised key, a revoked key, or a key in which the owner lost the private key. If you're the owner of a key that has an expired date, you *should* extend it to allow further use of the key by your contacts. If you decide you don't want to use the key any longer then you *should* revoke the key. If you accidentally lose your key then no worries, because eventually it will expire and nobody could encrypt to it even if they wanted to. Hope this helps, SAM -- GPG FINGERPRINT 4096 KEY 8D8B F0E2 42D8 A068 572E BF3C E8F7 3234 7257 E65F https://keybase.io/samrocketman ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: mailto with pgp fingerprint
I'm hoping keybase.io will hopefully resolve the issue of identity checking with key fingerprints. For example, my keybase account is... https://keybase.io/samrocketman My friends who regularly interact with me on github (and more rarely twitter) as well as the domain(s) I own will help to give my recipients the benefit of the doubt that my key is what I say it is when they only see it in an email. On Tue, Jul 22, 2014 at 10:27 AM, Werner Koch w...@gnupg.org wrote: On Tue, 22 Jul 2014 09:40, enigm...@josuttis.de said: More and more we seem to have the problem of faked keys in the key servers. This especially applies to well known keys such as authors of magazines and famous tools. This is actually the problem of checking the validity of the key. Granted, gpg is not smart enough to figure out the best matching key but that is something which can be fixed. A more simple way of tackling this is to use PKA or DANE for key validation: For sending mail you already need DNS and thus it would be easy to retrieve the matching key from the DNS. The drawback is that this must be configured by the key owner and can't be changed by the sender. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users -- GPG FINGERPRINT 4096 KEY 8D8B F0E2 42D8 A068 572E BF3C E8F7 3234 7257 E65F ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Heartbleed attack on Openssl
On Tue, Apr 8, 2014 at 11:01 PM, Felipe Vieira fmv1...@gmail.com wrote: Dear GNUPG community, I think a lot of unexperienced users would like to know more about the Heartbleed problem found on some of the openssl versions. I have two broad questions and two specific questions: 1) Which type of clients have been compromised (consider an ordinary user)? 2) Which common applications use openssl and are a potential target? 2) Are firefox users compromised? 3) Are RetroShare users compromised? Thanks in advance. For the most part it is service providers who are affected by the bug. There's a handy website to verbosely explain heartbleed. http://heartbleed.com/ Affected services include HTTP, email servers (SMTP, POP and IMAP protocols), chat servers (XMPP protocol), virtual private networks (SSL VPNs), databases (e.g. mysql), and pretty much any service that uses openssl TSL/SSL to secure transport of services if they're recently patched. Security notices for popular server distros... RHEL - https://access.redhat.com/site/solutions/781793 Ubuntu - http://www.ubuntu.com/usn/usn-2165-1/ CLIENT There's not much you can do at this point. Update your system packages and that's about it. SERVICE PROVIDER Essentially you want to take the following steps if you're service provider. 1. Test for the vulnerability - http://pastebin.com/WmxzjkXJ it is also prudent to search for the affected package versions across all services. 2. If vulnerable patch the OpenSSL version of public front end services first. Patch backend services after the front end is secure. 3. Reissue SSL private keys and certificates. Since the leak exposes the private key it is no longer pristine. For the remaining more thorough steps of what to do see the heartbleed.orgwebsite which has a nice set of instructions. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: It's 2014. Are we there yet?
On Wed, Apr 9, 2014 at 1:20 PM, Kapil Aggarwal ka...@hotmail.com wrote: - I don’t even know what I need. – Well, assuming they are starting to recognize the need, I suspect they will find out relatively easily as to what they need. With a few caveats of course. There’s way more FUD/noise/BS out there than the average person can decipher, so it’ll probably end as being word-of-mouth recommendations or such. - Even if I know what I need, getting it/installing it is hard. – It is. The setup/install needs to be simpler, i.e. as simple as installing an “app”. That is what the average Joe user is capable of. - WTF is a key pair/public key/private key/insert more arcane terminology… - This IS a big problem. I may get it, you may get it, how does the average Joe user gain that understanding? The nomenclature needs to be, well, something that the average Joe user can understand as well. They understood SSL (well, for the most part). -… several more similar arguments. Now, what will help drive this adoption more? - A better install experience? - A “dumbed down” (if you will) taxonomy that they can understand? - Simpler UIs? (without sacrificing secure functionality) - Better integration with existing systems? - Education? i.e. ongoing information dissemination that educates people on these things. Newsletters? How tos? Youtube videos (shudder)? And others. - Start hitting them on the head with a baseball bat? I've actually started talking to my family a lot about using it and getting my parents to use GNUPG. I think the biggest problem is too many paths to accomplish what is needed. There's so much software and so many recommendations that you, as an expert explaining to your friends, need to show them a single path and say, This is how it is done. I've written a document for my family and regularly link it on facebook encouraging friends and family to use it. Warning to PGP experts, the terminology is dumbed down and the concepts are filtered so not everything is technically correct but explained in a way that the user can understand. Also, it's a few pages of text and mostly screen shots. I tried making it fun somewhat so bear with the imagery. http://www.pages.drexel.edu/~sag47/privacy_for_everyone.pdf SAM ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: It's 2014. Are we there yet?
On Wed, Apr 9, 2014 at 3:23 PM, Daniel Kahn Gillmor d...@fifthhorseman.netwrote: Hi Sam-- [offlist for now, see why below] On 04/09/2014 01:29 PM, Sam Gleske wrote: I've written a document for my family and regularly link it on facebook encouraging friends and family to use it. Warning to PGP experts, the terminology is dumbed down and the concepts are filtered so not everything is technically correct but explained in a way that the user can understand. Also, it's a few pages of text and mostly screen shots. I tried making it fun somewhat so bear with the imagery. http://www.pages.drexel.edu/~sag47/privacy_for_everyone.pdf I'm really glad to see popularization of these tools. thank you for writing this up. i also really like your tinfoil hat photograph :) But... i read your disclaimer above, but the document (sha1sum 6dac22e5fa1095638149a537d6a3b641ad2dd551) has dangerously misleading directions. I strongly recommend you take it down for now while we figure out what to do about it. I haven't reviewed the whole document yet, but page 15 is particularly troubling. the problem is that you describe the concept of key validity, but associate it with key ownertrust. key validity is does this key belong to a person whose name and e-mail are indicated in the User ID? key ownertrust is am i willing to rely on identity certifications made by the holder of this key? These are entirely separate questions. I may know for sure that my boss's key belongs to my boss, but i don't want her to be able to create a new key that appears to belong to my husband, certify it, and send me mail that would then appear to come from my husband. Even worse, i wouldn't want my mail to my husband to be encrypted to this bogus key, because my boss could then read the contents of the mail. There are other problems with the text, including (from a quick skim, not exhaustive, ordered from trivial to security-critical): * page 17 is far too much information about a useless-at-best feature (see [0]) * the document recommends the use of pgp.mit.edu instead of the standard pool.sks-keyservers.net * the document discourages the creation of revocation certificates * page 11 seems to assume that asking their key ID is sufficient to verify identity, though this is distinctly not the case [1]. this is seriously insecure. I can send you a new OpenPGP key show private half i control, but with your user ID and your keyID later if you need convincing. :/ I recommend you read the riseup/debian OpenPGP best practices document [2] and the GnuPG DETAILS document and consider trying to align your document with the information and recommendations in those materials. I've left this message offlist for now, because i'm hoping you'll follow up on the message publicly and make it clear what your plan is with this document; If you'd like, either you or i can post these concerns publicly, and we can have the discussion on-list. But i think a quick note from you asking people not to rely on the current draft of that document while you revise it for clarity and correctness would be great. let me know what you think. sorry to send you a lengthy critique, and i hope it doesn't discourage you from continuing to spread the word about encryption. It's just important to avoid making recommendations that give people a sense of security that turns out to leave them vulnerable in hidden ways. All the best, --dkg [0] https://www.debian-administration.org/users/dkg/weblog/98 [1] https://www.debian-administration.org/users/dkg/weblog/105 [2] https://we.riseup.net/debian/openpgp-best-practices I agree with your concerns. In reality I only started using GPG a few weeks ago which would explain my amateurish approach I suppose. There is a source document written in openoffice... http://www.pages.drexel.edu/~sag47/privacy_for_everyone.odt Also, I have created sha1 files... just append *.sha1 to the file name e.g. http://www.pages.drexel.edu/~sag47/privacy_for_everyone.odt.sha1 For now I have removed the PDF since I have widely distributed the link to the PDF so that people don't download it and receive misinformation. The odt file remains. I'm open to editing the document for clarity and fact checking. Once, an acceptable revised copy is well received on the list then I'll recreate a PDF and upload it again. SAM ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Heartbleed attack on Openssl
On Wed, Apr 9, 2014 at 6:45 PM, Pete Stephenson p...@heypete.com wrote:
On Apr 10, 2014 12:22 AM, Felipe Vieira fmv1...@gmail.com wrote:
So going back to the original question as I can see there is no
disagreement on its importance:
1) What are the consequences to the ordinary user?
All the news are lacking information on that. Can you point relevant
examples?
In short: the consequences could be dire but there is no way of knowing
for certain what, if any, things have been compromised. Its probably best
to assume the worst.
^ That. Assume the worst because the vulnerability was there for two
years. Not sure who you're having a hard time convincing but send them to
heartbleed.com. The first three paragraphs are for high flying executives
whose business critical documents are at risk.
For example: Gmail and Dropbox and Hotmail seem to be imune to this. I
also found out that Mozilla/Firefox browser were also imune. If I would
persuade someone of this bug's importance, which other examples could I
give?
What type of person are you trying to persuade? If you download any of the
vulnerability test scripts in the wild you'll notice that the 64k output is
truncated and the script simply states you're vulnerable. Edit that
script so that it dumps the full 64k. While you're at it put that script
in an infinite while loop and dump the output to a file on disk. Then use
Firefox or chrome or whatever browser you want and log in to the service.
When you're done search the file for your credentials. It doesn't matter
what browser you're using.
2) (specific question) Does Firefox use openssl to connect to some
servers while browsing?
No. Firefox is immune because it uses the NSS Crypto library.
I have verified this claim. (Firefox Version: 28.0+build2-0ubuntu0.12.04.1)
$ dpkg -L firefox | while read x;do [ -f ${x} ] (if ldd ${x}
2/dev/null | grep libssl /dev/null;then echo ${x};fi);done | while
read x;do echo ${x};ldd ${x} 2/dev/null | grep libssl;done
/usr/lib/firefox/components/libmozgnome.so
libssl3.so = /usr/lib/x86_64-linux-gnu/libssl3.so
(0x7ffd9d836000)
/usr/lib/firefox/components/libdbusservice.so
libssl3.so = /usr/lib/x86_64-linux-gnu/libssl3.so
(0x7f778ceda000)
/usr/lib/firefox/libxul.so
libssl3.so = /usr/lib/x86_64-linux-gnu/libssl3.so
(0x7f326e66)
/usr/lib/firefox/browser/components/libbrowsercomps.so
libssl3.so = /usr/lib/x86_64-linux-gnu/libssl3.so
(0x7fa4537f3000)
/usr/lib/firefox/plugin-container
libssl3.so = /usr/lib/x86_64-linux-gnu/libssl3.so
(0x7f0807de7000)
$ dpkg -S /usr/lib/x86_64-linux-gnu/libssl3.so
libnss3: /usr/lib/x86_64-linux-gnu/libssl3.so
If it was openssl then it would be linked to
/lib/x86_64-linux-gnu/libssl.so.1.0.0 which is a part of the libssl1.0.0
package which is a dependency of the openssl package.
The issue typically exists on and affects servers. A server using an
affected version of OpenSSL is vulnerable regardless of what browser
clients use.
While it's true Firefox does not link openssl in binaries the vulnerability
allows an attacker to easily hijack sessions, steal usernames and
passwords, and steal the server private key during the SSL negotiation
phase. See my comments above for how you can verify that.
3) How about Ubuntu and other OSs? Do they use openssl to update
themselves? (as in apt-get update apt-get upgrade).
Ubuntu and Debian use GnuPG to sign packages but updates typically take
place over unencrypted connections. The update mechanism is not affected by
this bug.
True. $ grep -rH 'http:' /etc/apt/sources.list*
I'm not sure who you're trying to convince, Felipe, but HOPEFULLY you have
already handled this bug by patching and added rules to your intrusion
detection system for packets trying to attack SSL using this method (the
attack packets look very different from normal SSL communication).
Pete, forgive me breaking down your reply but I found it a good exercise in
attempting to verify your claims.
Environment
KUbuntu 12.04.4 LTS
Linux 3.8.0-37-generic x86_64
SAM
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Removing old preferences from exported key
There is also the clean command which cleans up old self sigs (among other things like unusable sigs, e.g. expired signatures). On Tue, Apr 8, 2014 at 1:48 AM, Johan Wevers joh...@vulcan.xs4all.nlwrote: On 07-04-2014 15:16, David Shaw wrote: When you change preferences you add another selfsig for your user ID that contains the new preferences. If you want to make the old preferences go away completely, you can simply delete the old selfsig via delsig Yers, that removes it completely from my keyring. That's not necessary and will be undone after the first sync with the keyservers anyway. However, is there a way to remove it from the exported key only - to keep the size of the exported key as small as possible? The export options didn't do that as list-packets showed. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Length for AES256 symmetric encryption passphrase?
On Fri, Apr 4, 2014 at 10:46 AM, Sam Gleske sam.mxra...@gmail.com wrote: On Fri, Apr 4, 2014 at 2:04 AM, Robert J. Hansen r...@sixdemonbag.orgwrote: Using plain English for the passphrase, a 170-character passphrase is necessary to provide a full 256 bits of entropy. Interesting math. However, I believe the OP mentioned they're generating the password and storing so human readable, i.e. English, isn't an issue. What would be the recommended length for completely random characters generated, for example, by a password manager such as keepassx? To clarify and be more specific... if one were using the password as the symmetric key in the GPG software (libcrypt)? Or perhaps even just using openssl tools? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Length for AES256 symmetric encryption passphrase?
On Fri, Apr 4, 2014 at 2:04 AM, Robert J. Hansen r...@sixdemonbag.orgwrote: Using plain English for the passphrase, a 170-character passphrase is necessary to provide a full 256 bits of entropy. Interesting math. However, I believe the OP mentioned they're generating the password and storing so human readable, i.e. English, isn't an issue. What would be the recommended length for completely random characters generated, for example, by a password manager such as keepassx? SAM ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Using an RSA GnuPG key for RSA ?
On Wed, Apr 2, 2014 at 3:14 PM, Leo Gaspard ekl...@gmail.com wrote: Were you to use the key both for gnupg and other systems, I would understand, but doing things this way...? I think generally it would be bad practice either way. A compromised server happens more often than a compromised gpg key. Therefore if a server gets compromised effectively your gpg private key has been compromised. It would be best to keep them separate entirely and not reuse the RSA key pair anywhere else. Treat your gpg private key like your identity (i.e. social security number) because it really is your identity... unless you want to go through the hassle of generating a new key and having your web of trust go through the hassle of resigning it when your RSA key gets compromised on a server. openssl tools are simple enough that generating throw away RSA keys is a no brainer. The same goes for most applications that support RSA keys. SAM ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Length for AES256 symmetric encryption passphrase?
You're making the assumption that 32 ASCII characters can produce every possible binary combination in 256 bits. I don't know how AES handles password phrases longer than 32 bytes but the key can be stronger I'd imagine with more random data as the key. I'm simply presuming. On Thu, Apr 3, 2014 at 5:21 PM, Barnet Wagman b...@norbl.com wrote: This a rather naive question, but I haven't found and answer to it. When doing symmetric encryption with AES256, is there any reason to have a passphrase that exceeds 32 characters (since that's the length of the AES key)? thanks ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Encrypted file-size approximation with multiple recipients
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On April 1, 2014 9:01:28 PM EDT, Tim Chase gn...@tim.thechases.com wrote: I've been trying to find a good explanation on how something like gpg -r DEADBEEF -r CAFEBABE -r 8BADFOOD -o output.gpg -e input.txt works. The best I've been able to find is this: http://lists.gnupg.org/pipermail/gnupg-users/2007-October/031938.html I'm mostly interested in the overhead, so I set up 4 distinct homedirs for testing. It looks like each additional recipient adds about 271 bytes (though one of them only has an extra 270 bytes), and there's a per-file overhead of about 66 or 67 bytes. So from my experimentation, the final file-size ends up being something like input_file_size + 67 + (271 * recipient_count) but I'm not sure how much that might change based on conditions I'm not taking into consideration (all my test GPG users were just g...@example.com, g...@example.com, etc), all with 2048-bit keys. Is there a more formal formula that can be used to approximate the overhead of multi-recipient encryption? Thanks, -tkc After reading in the gpg man page different recipients can have different key sizes. Additionally gpg will look at the supported cipher algorthms of all recipients and attempt to choose an algorithm common between them. That means your calculations aren't accounting for the different key sizes nor is it accounting for the size of the session key (session key is for the symmetric algo). You can go about this one of two ways. You can try write a program smart enough to account for that or you can keep it simple. KISS: assume worst case for every recipient and then do the math. e.g. 4096 bit rsa keys with AES256 cipher algo for the session key (assuming AES256 has the largest session key). At least that's how I would tackle it. SAM - -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQJABAEBCgAqBQJTO3m9IxxTYW0gR2xlc2tlIDxzYW0ubXhyYWNlckBnbWFpbC5j b20+AAoJEOj3MjRyV+ZfwtgP/2USc47Fsf6zk6qEq/ZbImdIhjZubhx8CDomkTz7 GKXzOGwHpWVC+WtUNI9Dm8L1LKe4vT/WBTbjLIMqF963ds4MAR5abQk/aRsf8COV pkjuY+FYEkcyQC0+1RWVQBakxm7Vp3WVLOOO5rlaj/5DULYhYiM7tEYPNR+Zk3ew dxf/27we6OTzWClVwGEYQ0R4uIyo5f7OyRpzLrRgvWZhds8zQW1ha2oNMQLupHll ZCibhNQ7W0rROqqk755c8lvlCSHz61g3IDvGQlpFWqo3iRVLJcW1/qa2Nz0Q0W3G M/CK7kW1R51Wp0/esN0qNo5+lFyt60c3BQSFBBm1RS7T72bo34KIjY0G9ytccaIp WhyTkVKZMx+kgpuFWsE5Ege+q42Wii3cNf1si0O2Iz72w9ckLBcNHj5ax1ndIm5o Ir1jx759+yPd2Jg+ctOeY+XKXOMgHxOygYRX6IPUYqm5+4aO4pUijIs5s6wge1+7 okseitw7/qvX0i7jr0DKLXUDYVYuuBvaBWiJs5gtJeKMFTl/tR5qLV4A0hTdKdPw 2p4Eb9Nm/w5FYUbQq/yAFpD2HHEN3MmCE40zpAGaDAGWCTN7FrJFo9tWhenyenhi bL0YPZ/OCeoFlg9QodaXiNLy5DwBp5DKx0dgJmxrAPU7LE7I5h/cGe3ShXelqxRq auFu =ku2m -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
