Storing GnuPG content of any kind (that is, plain text to be encrypted, encrypted text to be decrypted, even public keys from co-respondents) on disk can result in the same kind of vulnerabilities associated with storing any sensitive data on disk.

The existence of files containing encrypted data might be considered incriminating, depending on who finds those files; leaving files with plaintext output from decrypted messages may (obviously) compromise that plaintext if an attacker has access to the system. If such files are deleted, delete them securely or else they can be recovered almost as easily if they were not deleted at all.

Sometimes it’s best to encrypt a quick message by typing text at the command line, and having GnuPG output ASCII armored text that can be cut and pasted into a message, bypassing the need to store sensitive data–encrypted or not–permanently on disk.

This command is an example of entering a short message (“secret message for Peter”) at the command line:

The first part (echo "secret message for Peter") simply repeats the string “secret message for Peter”; the echo command can be used also to list a file to screen.

In this case, the output from the echo command is piped to another command, using the | character (vertical bar).

The command being fed the string should look familiar; GPG will encrypt the string to the public key associated with “Peter Loshin”, without the GPG software version information, as ASCII armored output.

WARNING: One of the benefits of using the command line is that commands are stored in RAM, and at the end of a session the command history is written to a history file. This is a benefit because it lets the user review, edit and resubmit commands. Of course, if the point of using the command line is to avoid writing sensitive data, it is important that the commands used are not stored in the history file. See Managing shell command history in OS X/Linux.

The result of this command will look something like this displayed in the terminal window:

This block of text can now be printed, copied into a web forum, instant message, email message, or stored on removable media.

On OS X/*nix systems, multi-line data can be entered using the backslash (“\”), like this (the “>” character on the following lines is supplied by the operating system and will not be included in the data to be encrypted):

$ echo "secret message for Peter\
>this is the second line
>this is the third line" | gpg --encrypt --armor --recipient "Peter Loshin" --no-version

The output will not look much different than the output shown above, but when decrypted, it will appear like this:

secret message for Peter
this is the second line
this is the third line

The most important tools in our society change not just the way we work but the way we talk and even think. If you’re not convinced, just consider all the different telephony-related phrases that have become an important part of the language: “please hold”, “party line”, “long distance”, “dialed a wrong number”, “hangup”, “off the hook”, “bad connection” are just a few. We adapt to working with new tools by learning new ways to talk about the experience of using those tools.

I’ve adapted to working with computers by translating computer-ese into my own internal understanding, and then doing the translation on-the-fly as I’m working. The more accurate my internal understanding is, the less likely I am to run into syntax errors when I’m programming.Continue reading →

One of the many benefits of using the command line shell in OS X or Linux (or any *nix or similar OS) is that the operating system keeps a history of all the commands you use, storing them in a dot file. These dot files are also known as hidden files, because they are usually hidden when you look at a listing of the directory (or folder, in the GUI).Continue reading →

Data stored on a cloud storage provider service is generally well-protected from routine eavesdroppers or man-in-the-middle attacks, but there remain other threats.

Consider Dropbox, just one of many new services provided online for storing data in the cloud. Dropbox is used here as an example because of its popularity and its commendable responses to attacks in the past.

Dropbox has used the experience they’ve gained while under attack to improve their security. Dropbox security policies are in line with industry best practices, but they must also align with industry best practices for running a web service.

This means that data stored on Dropbox may be vulnerable to attacks (for example) by government agencies armed with subpoenas or by criminals who attempt to coerce or extort Dropbox employees with access to customer data.

To prevent such unwanted access to data stored on Dropbox, it is recommended to encrypt data locally so that no one but you can retrieve the plaintext of your data.

There are tens of millions of pages of content on the web that address encryption or cryptography; that means two things: first, there is no shortage of good content explaining what encryption and cryptography are; second, there is also no shortage of not-so-good content that can be confusing at best, if not misleading or outright wrong and harmful at worst.

As with any specialty, one must consider the source before deciding whether the content is actually worthy of consideration. Reputation is crucial, especially when the information being provided will be used for security purposes.

Here are a handful of links to people and organizations that I consider trustworthy, either directly from personal interactions or from their public reputations as highly-regarded cryptographers:

Philip Zimmermann is the creator of PGP (Pretty Good Privacy), first published on the Internet in 1991, and the inspiration for the now standard Gnu Privacy Guard (GPG) encryption tool. Zimmermann’s crypto bibliography page is an excellent resource for learning more about cryptography as well as for links to reputable crpytography resources.

Gary Kessler’s An Overview of Cryptography is a comprehensive discussion of what modern cryptography is, what it’s for, and what tools are currently available.

HTTPS stands for “Hypertext Transfer Protocol Secure”. The protocol itself is the same as HTTP, but when a web resource is accessed via an HTTPS link the web client and web server negotiate a layer of encryption, with the goal of encrypting the web session (to protect that data from eavesdropping) and authenticating the web server (to prevent the user from man-in-the-middle attacks).

HTTPS Everywhere is a browser plugin (currently for Firefox and Chrome, though ports for other browsers may be available in the future) that forces “ordinary” web browsing sessions to use the HTTP Secure protocol to encrypt web traffic between the user and the server. HTTPS can reduce the risk of man-in-the-middle attacks while using popular websites.

HTTPS Everywhere protects against man-in-the-middle attacks, and it can encrypt the content being sent to and from your browser. It can protect that data from being detected by eavesdroppers, but they will still be able to see what website you are accessing, and if the website includes HTTP data (that is not encrypted) it may give an eavesdropper enough information to infer what your encrypted data is.

Steven Bellovin is now Chief Technologist of the Federal Trade Commission, and he opened his tenure with an excellent blog entry about passwords: Password Compromises, a follow up to one of former Chief Technologist Ed Felton’s last blog posts in that position, The Problem with Passwords.

Felten’s gist: passwords are tough to do right, need to be protected, and though we’ve been working on trying to fix them for a long time they’re still better than the alternatives. Meanwhile, use a two-factor authentication method wherever possible.

Bellovin’s gist: here are some suggestions for doing passwords correctly and securely, because these are some of the ways that your passwords can be attacked. Oh, and use a two-factor authentication method wherever possible.

As a counter-point, consider Which Password Manager Is The Most Secure?. Decent overview of the issues with passwords and password managers, but the first comment points out that if you use a proprietary web service, then you’re at the mercy of that service (e.g., if it goes out of business, you are kind of screwed). This of course goes for any proprietary solution of any kind, but it is a particularly bad outlook for this application (storing passwords), considering the implications of losing access to all one’s passwords.

So, it’s Thursday morning and I’m ready to start work, and I remember that I wanted to start logging my diet. Just write down a note to myself, every time I eat something: what did I eat? how much? when?

I’ve sort-of tried to do this with Listacular.com, but the process was too cumbersome, or else something else must have inhibited my doing it more regularly. I’ve had better success with using a paper and pencil approach, carrying a small notebook and pen or pencil with me at all times, and just making the note.

OK, fine. I’m thinking about how much simpler it would be for me to just use my phone because I always have it with me–and, finally, the lightbulb went off for me and I realized that I could take pictures of whatever I eat much more simply: just 2-3 finger-presses on the iPhone and I’ve got a record.

A record: and now I recall that there’s all that EXIF data associated with the image file, and then I wonder, just how much data can I pull out of a picture, and is there a way to add data–super-easily–when the photo is being taken?

and just click it and see how easily a person could be drawn into just going and installing that software (exif) on the Mac. But first, figuring out if I have Mac Ports installed, and so on and on: install this, enter that command.

But this kind of page helps me out, even if it’s not really an exact answer to my question, it raises (and even sometimes answers) other, related, questions about what I want to do and how I might want to do it. It gives me some rationale about how the thing works, and gives me actionable information: install this, type that. I know how it’s supposed to work, and I have an example of something that I can do to further my knowledge.

A bit of googling tells m fiddling with EXIF data is not a new idea, and there is a LOT for me to learn about EXIF–and there are a lot of resources for learning about it.

So, this is how I learn: get instructions with explanations, and context for how it all works, and an assignment to take action.