Archive for the ‘Integrity’ Category

A response to ‘Strong Encryption and Death’

2017-01-20 1 comment

I recently read an article on the TriLUG blog mirror discussing access to data after the death of the owner.  I’ve also given this a lot of thought as well and had previously come to the same conclusion as the original author of the article has:

“I created a file called “deathnote.txt” which I then encrypted using GPG.  This will encrypt the file so that both Bob and Alice can read it (and I can too). I then sent it to several friends unrelated to them with instructions that, upon my death (but not before), please send this file to Bob and Alice.”


To be honest, I didn’t actually go through with this project as there were just too many variables that I hadn’t figured out.  There is a lot of trust involved in this that potentially requires a very small number of people (2) to really hose things up.  It’s not that I wouldn’t trust my “trusted friends” with the responsibility but it potentially makes them targets and two is just a really low threshold for an adversary to recover this information.

What really threw me was that the author also included a copy of his private key in case they couldn’t locate it on his computer to, I’m assuming here, access other data.  I have one word for this: NOPE!

Okay, short of the private key thing, what was proposed was quite logical.  Like I said above, I had a very similar idea a while back.  Springboarding from that idea, I’d like to propose another layer of security into this whole process.

Splitting up the data

So you have your encrypted blob of information that goes to person A when you kick off but you don’t want person A to have it before.  Import some trusted friends and you have a means of providing the information to person A upon your demise.  But letting a single person, or even two people, control this information is dangerous.  What if you could split up that data into further encrypted parts and handed those parts out to several friends?  Then, not one single person would hold all the information.  You’d likely want some overlap so that you wouldn’t need ALL the friends to present the information (maybe it got lost, maybe the friend got hit by the same bus that you did, etc) so we’d want to build in a little redundancy.


Shamir’s Secret Sharing Scheme (ssss) is a neat piece of software that takes some information, encrypts it, and then break it into pieces.  Redundancy can be added so that not all parts are required to reassemble the data (think RAID 5).

“In cryptography, a secret sharing scheme is a method for distributing a secret amongst a group of participants, each of which is allocated a share of the secret. The secret can only be reconstructed when the shares are combined together; individual shares are of no use on their own.”

–From the SSSS website

Implementing the solution

Because ssss can only share relatively small strings (less than 1024 bits), my “death” instructions would likely need to be stored whole as a cipher text and the key (symmetric) being the shared object.

The other piece of this solution would be whom to get to hold the shared bits of keys.  It would likely be best if the individuals were not only trusted but also didn’t know the others involved in the share.  That way there is a smaller chance that these individuals could get together to put the key back together.

Also, if person A is the one holding the cipher text, even if the individuals did find each other they would only have a key and not be able to decode the actual texts.


I’m quite happy that I read the original article and I hope to do the same thing that the author did before I kick the bucket.  I’m quite sure that there are other ways to do what Tarus and I wrote about and actual implementation will vary depending upon the individual, their technical level, and their personal privacy requirements.  This problem, though, is one that deserves to be solved as more and more of our information is kept digitally.

Securing email to Gmail

2015-12-22 3 comments

I’ve been working on securing my postfix configuration to enforce certificate validation and encryption on some known, higher-volume, or more sensitive connections between SMTP servers (port 25).

On many of the connections I’ve setup for secure transport there have been no problems (assuming proper TLS certificates are used).  Unfortunately Gmail™ has been a problem.  Sometimes it verifies and validates the certificate and other times it doesn’t… for days.

After conferring with Google Security I believe I’ve come up with a solution.  In my tls_policy file I’ve added the following:       secure ciphers=high protocols=TLSv1.2

So far this is working but I’ll continue to test.

If you run your own SMTP server and wish to maintain a secure connection with Gmail this is an easy way to enforce encryption as well as validate the certificate.  Of course this doesn’t protect the message while it’s being stored on the server or workstation (or on Google’s internal network).  To protect messages at rest (on a server) one should use GPG or S/MIME.  Using both TLS over the network between servers and GPG or S/MIME is beneficial to provide protection of the messages going over the Internet.


This configuration is applicable with the OpenSSL version shipped with CentOS 6/RHEL 6.  Implementing this on CentOS 7/RHEL7 or another flavor of Linux may require a different/better configuration.
The policy has been updated for CentOS 7/RHEL 7 which supports TLSv1.2 on Postfix.  Other services can also be setup similarly:    secure ciphers=high protocols=TLSv1.2    secure ciphers=high protocols=TLSv1.2    secure ciphers=high protocols=TLSv1.2    secure ciphers=high protocols=TLSv1.2

Postfix Encryption

2015-03-12 3 comments

I’ve been tinkering with the encryption options in Postfix for a while.  Encryption between clients and their SMTP server and between SMTP servers is necessary to protect the to, from, and subject fields, along with the rest of the header, of an email.  The body of the message is also protected but it’s always better to utilize PGP or S/MIME cryptography to provide end-to-end protection; encryption between clients and SMTP servers doesn’t provide this.

As rolled out now, encryption between SMTP servers is opportunistic encryption and is generally not required.  While doing a review of my mail log I seem to be receiving most personal mail via some encrypted circuit while much of the mail coming out of listservs, like Yahoo! Groups, is not negotiating encryption on connect.  I’ve also noticed that some email providers actually run their incoming email through an external service, I suspect for spam control, before accepting the message into their servers.  Some of these spam services don’t support encryption making it difficult to protect mail in transit.

Postfix documentation is pretty decent.  The project seems to document most settings but sometimes they don’t actually put the entire picture together.  Encryption is one of those things where a complete picture is difficult to put together just by looking at a single page of documentation.

Postfix’s documentation on TLS is fairly complete.  What they miss on that page, forward security, must be found else where.  Until last night, I had missed that last page and now have fixed my configuration to include, what I consider, acceptable settings.

Here’s what I’ve got:

### TLS
# enable opportunistic TLS support in the SMTP server
smtpd_tls_security_level = may
smtpd_tls_eecdh_grade = ultra
tls_eecdh_strong_curve = prime256v1
tls_eecdh_ultra_curve = secp384r1
smtpd_tls_loglevel = 1
smtpd_tls_cert_file = /etc/pki/tls/certs/mail.crt
smtpd_tls_key_file = /etc/pki/tls/private/mail.key
smtpd_tls_CAfile = /etc/pki/tls/certs/mail-bundle.crt
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtpd_tls_received_header = yes
smtpd_tls_ask_ccert = yes
smtpd_tls_received_header = yes
tls_random_source = dev:/dev/urandom
#TLS Client
smtp_tls_security_level = may
smtp_tls_eecdh_grade = ultra
smtp_tls_loglevel = 1
smtp_tls_cert_file = /etc/pki/tls/certs/mail.crt
smtp_tls_key_file = /etc/pki/tls/private/mail.key
smtp_tls_CAfile = /etc/pki/tls/certs/mail-bundle.crt

submission inet n       –       –       –       –       smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_sasl_type=dovecot
-o smtpd_sasl_path=private/auth
-o smtpd_sasl_security_options=noanonymous

Those familiar with setting up TLS in Apache will notice a few differences here.  We haven’t defined ciphers or SSL protocols.  This is because this is opportunistic encryption.  We’re just happy if encryption happens, even using EXPORT ciphers, since the alternate is plaintext.  In a more controlled setting you could define the ciphers and protocols and enforce their use.  Until encryption becomes the norm on the Internet (and why shouldn’t it be?) I’ll have to stick with just begging for encrypted connections.

It should also be noted that client-to-SMTP server connections are forced to be encrypted in as seen in the submission portion.  This was a quick and dirty way of forcing encryption on the client side while allowing opportunistic encryption on the public (port 25) side.

It should be noted that ECC keys can be used with Postfix, which forces good ciphers and protocols, but most email servers have RSA keys established so problems could arise from that.  Dual keys can always be used to take advantage of both ECC and RSA.

As SSLLabs is for testing your web server’s encryption settings, so is CheckTLS for checking your SMTP encryption settings.  These tools are free and should be part of your regular security check of your infrastructure.

CERN cares about information security… what about you?

2015-03-08 Leave a comment

As a security engineer it’s usually difficult for me to endure many of dumb things companies do.  It’s quite sad when a company that prides itself on creating solutions for building internal solutions to protect customer data actually starts pushing its own data out to Google and other “solution” providers.  It’s as if they don’t actually believe in their own products and actually think that a contract will actually protect their data.

So it’s quite refreshing when you run across a group that actually gets information security.  Recently, I ran across the information security bulletins at CERN (particle physics is another interest of mine) and was excited to find a group that actually gets it.  They provide internal, secure solutions for getting their work done without using outside solutions such as Google, Apple, Microsoft, Amazon, and Dropbox cloud solutions (I wish more of the internal solutions were FOSS but…).  In fact, CERN feels externally-hosted solutions are a bad idea for both business and personal uses.  I concur.

Here is a sample of their infosec bulletins:

What about you?  Do you care about the security of your information?

Securing Secure Shell

2015-01-06 2 comments

I was passed an interesting article, this morning, regarding hardening secure shell (SSH) against poor crypto that can be a victim of cracking by the NSA and other entities.  The article is well written and discusses why the changes are necessary in light of recent Snowden file releases.

Automated configuration analysis for Mozilla’s TLS guidelines

2014-10-09 Leave a comment

My friend Hubert has been doing a lot of work to make better the world a little safer.  Glad he’s getting some recognition.  Here’s a great article on testing your server for proper SSL/TLS configurations.

Signing PGP keys

2014-06-21 2 comments

If you’ve recently completed a key signing party or have otherwise met up with other people and have exchanged key fingerprints and verified IDs, it’s now time to sign the keys you trust.  There are several different ways of completing this task and I’ll discuss two of them now.


CA Fire and Forget (caff) is a program that allows you to sign a bunch of keys (like you might have after a key signing party) very quickly.  It also adds a level of security to the signing process by forcing the other person to verify that they have both control over the email address provided and the key you signed.  The way caff does this is by encrypting the signature in an email and sending it to the person.  The person who receives the message must also decrypt the message and apply the signature themselves.  Once they sync their key with the key server the new signatures will appear for everyone.

$ gpg --keyserver hkp:// --refresh-key

There is some setup of caff that needs to be done prior but once you have it setup it’ll be good to go.

Installing caff

Installing caff is pretty easy although there might be a little trick.  In Fedora there isn’t a caff package.  Caff is actually in the pgp-tools package; other distros may have this named differently.

Using caff

Once you have caff installed and setup, you just need to tell caff what key IDs you would like to sign.  “man caff” will give you all the options but basically ‘caff -m no yes -u ‘ will sign all the keys listed after your key.  You will be asked to verify that you do want to sign the key and then caff will sign the key and mail it off.  The user will receive an email, per user id on the key, with instructions on importing the signature.

Signing a key with GnuPG

The other way of signing a PGP key is to use GnuPG.  Signing a key this way will simply add the signature to the key you have locally and then you’ll need to send those keys out to the key server.

Retrieving keys using GnuPG

The first thing that you have to do is pull the keys down from the keyserver.

$ gpg --keyserver hkp:// --recv-keys ...

Once you have received all the keys you can then sign them.  If someone’s key is not there you should probably contact them and ask them to add their key to the servers.  If they already have uploaded their key, it might take a couple of hours before it is sync’d everywhere.

Using GnuPG

Signing a key is pretty straightforward:

$ gpg --sign-key 1bb943db
pub 1024D/1BB943DB created: 2010-02-02 expires: never usage: SC 
 trust: unknown validity: unknown
sub 4096g/672557E6 created: 2010-02-02 expires: never usage: E 
[ unknown] (1). MariaDB Package Signing Key <>
[ unknown] (2) Daniel Bartholomew (Monty Program signing key) <>
Really sign all user IDs? (y/N) y
pub 1024D/1BB943DB created: 2010-02-02 expires: never usage: SC 
 trust: unknown validity: unknown
 Primary key fingerprint: 1993 69E5 404B D5FC 7D2F E43B CBCB 082A 1BB9 43DB
MariaDB Package Signing Key <>
 Daniel Bartholomew (Monty Program signing key) <>
Are you sure that you want to sign this key with your
key "Eric Harlan Christensen <>" (024BB3D1)
Really sign? (y/N) y

In the example I signed the MariaDB key with my key.  Once that is complete a simple:

gpg --keyserver hkp:// --send-key 1BB943DB

…will send the new signature to the key servers.

Categories: Integrity, OpenPGP