When you connect to a remote server, you’re connecting over ssh or scp or a similar protocol. In each case, you may have to provide some authentication credentials to prove you are who you say you are. This can come in the form of a user/password combo, but if you’re connecting a lot or if you’re trying to setup a non-interactive connection, this can become either really monotonous or really problematic. Public/private keys will come to our rescue, and we’ll never need to enter our password again.
Around the office, when someone security-minded finds out that I instant message (IM) over Pidgin (using Google Talk’s service), there tends to be wailing and gnashing of teeth, because I am chatting in clear text over the wire. I am encouraged to use a clunky, Windows-only, proprietary, corporate, different tool that is for internal talk with internal people. “It’s secure.” “It’s encrypted,” they say. I never though I said too much of worth over chat, and what was occasionally awesome was well-encoded in l33t. But, now my friend Dean teaches me the goodness of encrypting your IMs in Pidgin.
Recently, I’ve been working on a project where I’ve tried to use AES encryption for the first time. I didn’t have to implement it myself, thank goodness, but I still ran into a few snags. Perhaps you can avoid my pitfalls and rise to new greatness on the peaks of glory and fortitude! This article title sounds like a laundry detergent.
By default, Java has a limit on the length of your encryption key. The limit, by default 128-bit, seems a little small and dated. So, let’s break through that glass ceiling! With the hammer of Thor!