Loshin.com

diff is a *nix command that takes two files and compares them, reporting on the differences between them. For example:

$ diff foo.bar foo.bar
$

When the files are identical, no output is generated (as in this case, comparing a file to itself).

The problem with diff is that its output may not be immediately obvious to the ordinary user. For example, consider the two files:

FIRST LINE = 'foo.bar'
this is a simple 3-line file
this is the third line

and

FIRST LINE = 'foo.baz'
this is a simple 3-line file
this is the third line
AND SURPRISE! a fourth line

Run diff like this:

$ diff foo.baz foo.bar
1c1
< FIRST LINE = 'foo.baz'
---
> FIRST LINE = 'foo.bar'
4d3
< AND SURPRISE! a fourth line

The output is very clear--if you are a computer. diff is particularly useful for using in scripts that look at two files and then pass along the differences to some other program, which can then do something with that information automatically.

As a human being, it's not immediately clear--until I can understand how it works: the output indicates what lines in the first file have to be changed to make it identical to the second file. The output starts with a line number(or line numbers) in the first file, which indicates where in the file there are differences. Next, a letter that tells me what needs to happen with that line(s) in the first file, and finally, the line number(s) from the second file that need to be added, changed or deleted ("a" for add, "c" for change, and "d" for delete).

Following the codes that specify line numbers and action, there will be one (or more) lines underneath, with either the "<" or ">" symbols at the left. ">" means "put this in" and "<" means "take this out".

The first 4 lines of the diff output, 1c1 tells me that I need to change the first line in foo.baz from “FIRST LINE = ‘foo.baz’” (delete the first line) to “FIRST LINE = ‘foo.bar’” (add that as the first line).

The last two lines tell me that I need to delete the fourth line, and then the files will be synchronized from the third line onward.

Comparing the two files the “other” way gives this result:

$ diff foo.bar foo.baz
1c1
< FIRST LINE = 'foo.bar'
---
> FIRST LINE = 'foo.baz'
3a4
> AND SURPRISE! a fourth line


This time, the first line needs to be changed, but instead of deleting a line at the end of the file, an extra line (“AND SURPRISE! a fourth line”) needs to be added to make the two files identical.

It makes more sense the more I experiment with files that are almost identical and use diff to see how it works.

• Paul Heinlein’s GPG Quick Start (very basic, but useful)
• The GNU Privacy Handbook (more a how-to for gpg, plus concepts)
• GnuPG FAQ (some helpful things here, but pages more likely will be found via google)
• Using the GNU Privacy Guard (advanced stuff)
• GnuPG – Command Reference (by Eric L. Howes) (good resource, has decent explanations of some things)
• A Beginner’s Guide to GnuPG (on ubuntuforums.org) (not bad, but typical–also, too many add-ons/programs)
• How to revoke a key or Can I delete a key from the key servers? (just one topic from the GPGtools site, but worth looking at)
• Revoking key components (from GNU Privacy Handbook) (good for more about revocation from gpg –edit-key interactive prompt)

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:

• Bruce Schneier is the internationally-renowned security technologist and author, and the author of Applied Cryptography: Protocols, Algorithms, and Source Code in C, Second Edition, for almost 20 years the canonical resource for programmers who need to implement cryptographic functions. Schneier’s personal blog is an excellent source for current and correct discussion of cryptography and security issues.
• 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.

Protect those 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?

So, the first question, what data is there, I ask Google:

what information is stored in photo in iphone

and the first link is this one:

What information is stored in EFIX/JPEG photos taken on the iPhone with geotagging enabled?

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.