Java: PGP Sign and Encrypt Strings

Source Code

Speaking at Hope X in 2014, Edward Snowden suggested developers should champion design solutions that implement information encryption-tech as a first class citizen. Without getting too nuanced about what that means, here are a few technical thoughts on a design solution I ran across while implementing a solution recently.

Forgetting that PGP tools are poorly adopted for even their most prevalent uses cases like simple E-mail communications: they're even less prevalent in the simple messaging systems that users often find themselves interacting with in web-based messaging applications.

I would argue that even if a software architect would like to have these solutions implemented, there exists a real lack of developer APIs to streamline implementing these processes.

One of the first things that strikes me when I Google DuckDuckGo for a library or source-code examples for putting PGP into my software applications, is that most examples uses these tools to PGP encrypt files on disk!

When is the last time, in 2014, you as a developer implemented your solution to read and write your users messages to a FLAT-FILE SYSTEM ON DISK?!

The answer is: YOU DON'T. Your solutions pass messages through in-memory strings, that are saved in a database or e-mailed or streamed to your users browsers!

In this simple example, I'm using a few methods to read-in a set of PGP-keys I've generated (Yes -they're stored on disk*) and 1. Generate a PGP Signature of my string, using my private-key, and 2. Encrypt my message with my public-key. Without reading or writing the message from DISK!



I'm using Java's Bouncy Castle library. The "Documentation" is pretty dense. So I ended up looking for an example that fits this use case.

First, in Java, it's important to add BC as a "Security Provider".

Note: In a cute-irony the Bouncy Castle libraries WILL FAIL to work properly unless you update your Java JRE with the Unlimited Strength Jurisdiction Policy files. Implementing source code that helps the North Koreans or the Iranians encrypt their E-Mails may result in 20-years in a "Pound me in the Ass Federal Penitentiary"? That's right. You've just cross the thin-red line, bro, no turning back now. (Que Scene from Office Space where they install the virus...)

Next we need to to actually load our PGP-Key files. Which is easier said than done. The API's in bouncing castle and most other libraries behave in a key-chain manner, where we can load a file that contains multiple keys.

And the Private-Key:
Something to note here, we're opening the "Secret Key" key: which ISN'T actually our Private Key in code, this is because our priv. key is still hashed with the password I set when I created it.

So we need to unlock it. This is the first place I got an exception before I updated my JRE (See above)

Ok, cool. We've got our keys! Now here's the trick, we're going to take our input string and perform the signature and encryption with it them:

First with our private key, we want to sign our message:

Keypoint...

That was dense. And to be perfectly frank, the fact that I can't wrap this operation into a method: Is one of the major issues why developers aren't making encryption a first-class citizen in their implementations.

Moving on.

Next, we want to encrypt our string.


Again, pretty dense. A few things to note in the above routine: Some of the methods are now marked as deprecated in Bouncy Castle, which arguably is more important when dealing with cryptography than any other area of writing code. For brevity however, I'm not going to let perfect be the enemy of good in sourcing this out.

* Storing of the actual key-files is something of a conundrum to me. The simple solution of storing a public-key in a database makes the most sense, as you could encrypt messages before they are transmitted from your web-application. However, how to safely "store" a private-key in relationship to your executing code is a matter for a real security expert in key-storage.

A hardfork of the Bitcoin blockchain is coming, here's why

Edit so people don't think I'm just trolling, here's a synopsis:

1. A major payment provider partners with a large mining hardware provider to process and generate Bitcoins
2. The miner / payment provider collude to introduce "taint" into the Bitcoin system thus creating a "token" like system of tainted Bitcoins' that casual users whom never spend their BTC outside of this loop use.
3. The tainted coins grow in size until enough mining power is achieved in the tainted coins that anonymous coins begin to lose value creating a snowball affect and thus an eventual hardfork.

No ads on this site, though if you'd like to join an up-and-coming Bitcoin Exchange, please consider: Bitfinex, and using my referral code (kwr9f922HS) for 10% of exchange fees for the first 30 days. You can go long/short the market and also lend your Bitcoin, Litecoin, or USD to other traders for interest. Thanks.

Bitcoin's underlying technology, "proof-of-work block-chaining" maintains it's integrity through some simple rules:

1. Distributed consensus of transactions verified by immense amounts of computation power to avoid corruption (SHA hashing block-discovery)
2. No central code base, meaning core developers could modify the way the software works but a majority of miners would have to "accept" and "implement" this change in order for it to have an affect on the larger ecosystem. (Double blind)
3. No central servers of mining locations (no single point of failure in the system)

During my conversations with other's in the community, there is lots of discussion about the danger of a 51% attack, and recently more conversation around "coin-taint" (a sort of scaling back of the anonymous characteristics of Bitcoin). The first being a "bridge too far" in my mind, but the later having some interesting consequences.

Here's why:

Today there is no such thing as an 'anonymous electronic transaction' outside of Bitcoin in the world. Most countries in the world follow the same sets of electronic financial transaction rules and regulations in order to participate. See Walter Stanish's excellent explanation here.

Therefore, I submit, that a payments corporation, lets say "Visa", as an example could launch something of a "progressive taint" attack on the Bitcoin block-chain, under the guise of "Bringing Bitcoin mainstream" all the while taking progressively larger control of the network until a hard-fork occurs.

Step 1:

Our corporate payments processor partners with a large institutional retailer (lets say Amazon) and announces the acceptance of Bitcoin! Amazing! Bitcoin can buy anything in the universe that Amazon sells now, and everyone will be turning in their USD for Bitcoins to buy buy buy this Christmas.

But there's a catch - the Bitcoins Amazon/Visa accept for payments may start out as plain ol' Bitcoins, but through a clever use of the block-chain, this large retailer's payment processor can introduce "taint" into the coins that it touches: Marking them in some way so that they can be tracked once they are than sold back into the digital ecosystem.

Step 2:

Miners and users could easily strip out this taint, and tumble the coins, cleaning them so to speak. But one also has to remember that there is a large contingent of mining hardware sitting idol that has long since past it's profitable life.

The payments processor could offer incentives to the miners to begin mining again with their hardware, and pay them a nice premium to hash blocks, so long as the only transaction they include in the blocks include taint for tracking customer information (a valuable commodity to any corporation, and one that the cost of tracking customers spending habits in Bitcoin would easily be worth making)

Bitcoin Mining BORG

Step 3:

Once the the payment processor has captured a large enough potion of mining hardware, they can essentially hard-fork the block-chain into: "tainted and untainted" sets of coin transactions. Tainted transactions with all the history and identifying factors a traditional financial institution requires of it's customers now are useful to the payments processor. Sure "traditional" anonymous Bitcoins will still exist, just like cash, but like the cartels cash, you can't just deposit at your local 'Wells Fargo'.

Feel free to post your disagreements with my theory I would love to read them. This isn't ground-breaking stuff. I'm just pointing out the rather obvious fact that Bitcoin (as it exists today) will never be a mainstream payments system without taint.


Full Disclosure: I actively trade, and mine Bitcoin, and Litecoin, and have worked on a variety of projects in the space. I day trade and so am neither long/or short any positions in Bitcoins for very long.

Other interesting reading on Bitcoin blockchain forking:

http://arxiv.org/abs/1311.0243 (Selfish mining paper)

To get out of my contract with T-Mobile: I'm suing

T-Mobile has recently been holding themselves out as the first wireless carrier to ditch the "contract for subsidized headset" business model. The wireless carrier instituted this pivot in early 2013, in what I assume, was an attempt to gain back some market share. 

T-Mobile has lost ground in recent years: they were one of the last carriers to offer the iPhone in the US and had one of the slowest LTE Rollouts. Again both of these changes happened in early 2013, so it's safe to say T-Mobile is into a "full court press" to keep from falling into irrelevancy in the US domestic market following the failed takeover bid by AT&T. 

Needless to say, before this abrupt "about face" T-Mobile followed the cut and dry business plan carriers have been following since...well...whenever...subsidized headsets in exchange for service agreements.

So when I became dissatisfied with my service, I didn't expect much, and I wasn't wrong. T-Mobile is amongst the most often complained about consumer product companies. 

A few hours with of phone-calls to T-Mobile yield "technical support" such as: "visiting a T-Mobile store" (Where an employee suggested I download a "signal boosting app") or that I "reset" the headset, and call them back if things did not improve. When asked: "What is T-Mobile's accepted dBm range to be considered providing the superior quality of service you speak of given my proximity to a newly LTE enabled tower?" the response: "dBm? What's that?" 

Sex-appeal not quality of service

T-Mobile does not offer "Micro-Cells" for low-quality service areas, but instead relies on built in "wifi-calling" features on most of it's WiFi enabled phones. A feature that is of "dubious quality at best". 

I have an Comcast Wireless-N Router and a 2nd router Linksys WRT310N running DD-WRT as a repeater in my 1200 sqft. apartment, and I am still unable to maintain a phone-call at near "acceptable quality", for example, the call not dropping at least once every 5-10 minutes. 

On the phone with T-Mobile customer support, I was repeatedly offered a minor service discount: 10% a month for 6-months. I eventually learned that like T-Mobile's "Consumer Relations Office" a PO BOX in New Mexico, the only way to "escalate further" is to contact T-Mobile's "legal department" by written correspondence only.

So with the help of my attorney, that's exactly what I've done. 

My attorney has dispatched a demand letter that spells out my specific complaints, my experience, and my desire to terminate my relationship with T-Mobile without the prejudice of a $300 "early termination fee".

You might wonder why I'm so worked up about $300? Most days I make that before lunch. The money is hardly the issue. The issue I want to address is:

"the abuse of contractual clauses and terms of service agreements by large companies against their customers because most consumers are unwilling or unable to take legal recourse to defend themselves."

Other companies Google or Paypal, are infamous for using "terms of service" agreements to terminate relationships with or without due process of law.  

The age of quality service in America maybe long dead, but I want to fight to make sure that "terms of service" stand the litmus test of a "court of law" before I give T-Mobile another dime of my hard-earned money.      

I will update with the results of this little experiment. If T-Mobile responds to my attorney with a less than favorable result, I will be moving forward with litigation 

In case you're curious (and if you found this I'm sure you are):

T-Mobile's Legal Department Address  
12920 SE 38th St., Bellevue, WA 98006-13850
No phone number provided, or listed.

T-Mobile's Consumer Relations Address
P.O. Box 37380 Albuquerque, NM 87176-7380
No phone number provided, or listed.

Legal services provided by: Dell Law Office

Screen Captures

No service @ Home 

"Data Roaming" warning on my patio

T-Mobile US LTE ECN Setting

New high-rise construction is taking place (2012-2015) in-between my apartment and all local towers

Open Signal is an excellent free tool to monitor your coverage and tower locations

Demand Letter T-Mobile

Bitcoin exchanges: "Flying Under the Regulators Radar"

Regulators searching for Bitcoin exchanges

I think some of the most exciting advances in BTC Trading Technology and Exchanges are doing their best to remain "under the radar" due to intense fears about their "legal status" as money-service's businesses, etc. 

Read an interesting piece today about the 'rent vs. own' aspect of becoming a MSB and how CoinX (July's winner of best start-up pitch at Light Squared Ventures Bitcoin Night, which I attended) is obtaining their own MSB license in every-state they want to operate, instead of going the 'rent' route. 

http://www.paymentssource.com/news/in-money-transmitter-licensing-is-it-better-to-own-or-to-rent-3015198-1.html 

So that explains why they're so quiet...don't splash the pool well your trying to swim across. At the same time are they sacrificing 'first mover advantage'? 

Some foreign exchanges like HK based Bitfinex (full disclosure: I'm a user there) - have gained volume and the financial strength to push forward with licensing in the US. The unanswered question is: are they doomed to go the MtGox route and have accounts shuttered at the slightest sign of indiscretion? 

At the same time, those chasing 'First to Market' with professional market features like NYC based Coinsetter are in private-beta, and paper-trading mode, presumably why they wait to clear regulatory hurdles. 

There's also Atlanta, based CampBX, whose live market is begging to show signs of life inspite of a rather uncertain regulatory environment, they maybe the most active real-money BTC exchange in the US...

Others maybe just going for it, like Australian(?) based BTCSX 

http://www.zdnet.com/startup-opens-bitcoin-only-margin-trading-platform-7000019715/ 

---

So I want to propose a question: Are all Bitcoin Related Businesses the same?

The recent New York State financial regulation probe not withstanding. Should regulators consider separating "Exchanges" into a separate category than "Broker/Dealers" or "Payment transmitters" based on the types of financial services they offer? 

Early exchanges (MtGox for example) offer payment processing APIs and other features that more closely resemble a blended service like a traditional banking institution, but we've seen the last days of the "Non-banking Entity" fade on Wall St. and if history is any mean, I think Bitcoin's history is like the 200 years of western banking compressed into a few short years! 

It certainly still seems like the Bitcoin Exchange Game is one of a 'baby deer' lost in the regulators 'woods', and for those hard-core Bitcoiners' it's easy to forget: Bitcoin itself maybe pretty resilient, but, as one of the speakers at Bitcoin 2013 pointed out, it could be regulated until it becomes inconsequential.  

Mentioned Exchanges: CoinX (www.coinx.com), Bitfinex (www.bitfinex.com), Coinsetter (www.coinsetter.com), MtGox (www.mtgox.com), BTC.sx (www.btc.sx) and CampBX (www.campbx.com)

PGP Privacy 2 Go

So if your like me, seek help.

I mean seriously. These morbid delusional fantasies about the future of war and technology? Staying awake all night writing software to trade internet funny money (read: Bitcoin)? You get the picture. Your fit for a straight jacket.

Or you need a vacation. Which means it's time to hit the road without your trusty "security hardened" laptop. Your machine is security hardened right? You haven't been using those 'cloud based' services have you!? You host your own email, file sync, music streaming, calendar, and social network from a server under secure lock and key on a redundant internet connection to your condo right?! Not. The cloud is a convenient solution for all of this, unfortunately, it's also an extremely convenient solution for the government to spy on you.

Lets leave the politics of it out here. That's not the point of the post. You want to use Gmail. I get it. I use it. It's fast, reliable, it's servers are these crazy shipping container lego-blocks that can be shipped by train into Mexico in the event of nuclear war...making your email more safe from radiation poisoning than your sorry Starbucks sipping ass. Jordan searches frantically for his stash of iodine tablets but only discovers used Starbucks gift-carts. 

So the next best thing before you go-ahead and upload your email messages to the Utah Data Center for NSA perusal, is to use PGP, which if your reading this I'm relatively confident your already familiar with. If not, it's not hard to understand, but next to retarded difficult for your everyday operating system manufacturer, or email service provider to include with their services.

Once your email is encrypted with PGP, short of obtaining your private key from your physical machine (more on that later), it's extremely cost prohibitive, if not impossible, for anyone but it's intended recipient to read it while it sits for eternity on a hard-drive in central Utah.

The issue for most people whom have taken this precaution, is that the tools are inconvenient. For example, they, unlike your modern email client (Gmail) aren't as portable. Take for example, GPGMail, a reliable and improving tool for managing for managing PGP messaging with OS X Mail on top of OpenPGP. Great already hard enough. At least it grabs public keys attached to emails from your comrades, and stores them for future use.

You see what I'm saying, no wonder no one uses this stuff. Too fucking hard.

In that case... what happens once you've got some encrypted communication going on, and you want to read / send encrypted emails on the go with Gmail? Enter Mailvelope. A handy browser plugin, that allows you to PGP encrypt your webmail as your composing and reading on the go. With Chrome Browser Sync, once you login to your browser, this plugin should be made available to you where-ever you go. As inconvenient as it might be, the last little bit is to hang-on to your private key. I'll leave that part up to you.

Mailvelope Homepage

The issue I ran into was, I had already generated my PGP Pub/Priv key pair on my home machine, and wanted to use it while I was on the go.

Nothing abstract here.

Just a little demo of how to use the same private key to read your encrypted emails using Chrome.

Ok, so first we need to "export" our private key out of our PGP Keychain. Go ahead and open up the keychain in OS X (I usually type "Keychain" in the Spotlight search).

Go ahead and cmd-click, your key-pair, and choose "Export".

Make sure 'Allow secret key export' is checked. Once this is done, the text-file you create will be your "key to the kingdom" so to speak, as it will include a public and private key-pair. 

Doesn't look like much. But there is a lot of information here. Most importantly, your private key should only be placed and left on a browser on a machine you trust won't be compromised.

 Next, lets install the Mailvelope plugin on our Chrome Browser:

Once installed, go ahead and open the plugin (from it's setting's button on the top-right corner of the browser), and than choose the "Import Keys" menu.

This was kind of confusing for me, as I didn't realize you could also import private keys here. I gave it a shot, and it worked. So good on you Mailvelope. 

Paste the entire text of the Pub/Priv key-pair file you just exported into the text box.

Ok, now your good to go. 

Next, open up Gmail and start to compose a mail, and you'll notice a new little button, click it to open a PGP Mail composer from Mailvelope. Hit the "Lock" button.

And than choose your recipient (I'm sending this message to myself to demonstrate).

Your message is encrypted using the public-key of the recipient.

Now the message is placed in the composer as a PGP encrypted message, safe and secure, ready for upload to the government (:

Last step, receiving, and decrypting PGP encoded mail. I hit send, and the message appears in my inbox, as I was the intended recipient. The message is encrypted, but Mailvelope adds a button to my Gmail editor window to decrypt it. I click it, and am asked to unlock my private key (the private key passphrase is sort of a security of last resort to keep others from reading your messages)

And walla, your message is decrypted and has a "water-mark" behind it which has some significance, though I didn't read that far into the Mailvelope documentation.

PGP encrypting security tends to break down around "Physical breaches" of your private key. If you carry it around on an unencrypted USB-stick, or it's stored on your "secure machine" (read: laptop protected with your ex-girlfriends favorite nick-name for your penis as a password), there is a pretty good chance it can be compromised. 

There is more here, consider using a public-keyserver. These servers allows others to grab your key, and encrypt messages to you without you handing them your public key via a message. It also allows you to, in theory (I believe), issue a certificate with a key that allows you to "expire" the key-pair periodically, in-case of theft. Though that is beyond the scope of this blog post, I will be looking into that more in the future, but lets keep it simple for today.

As for physical security, I recommend a gas-powered AR-15 Platform rife, and a few hundred hours of close-quarters combat training. If you don't have this, maybe a mean dog, and a deadbolt. We're all susceptible one way or another...at least now your a little less so to government intrusion into your email box.

Evangelizing "MEAN STACK"

Any self-respecting "Brogrammer" like me knows how to program in Javascript. When startups try to test your skill set in "lingo" like: "Backend" (and by backend I mean...you an ass man, bro?) Your typically response is: "a whole bunch of stuff that isn't Javascript." 

Guess what: with MEAN STACK, Not anymore dude. Yeah, you just went from alert('Hello World'); monkey to full-stack developer...HIGH FIVE.

For a good time, check out: Brosciencelife on Youtube

MEAN STACK, as conceptualized by Valeri Karpov in the blog post linked above, is not new technology, and it's not even based on any new components. It's just, in my opinion, an exciting layering of existing technologies that all run on Javascript: mongoDB, ExpressJS, AngularJS, and NodeJS. And let me tell you: this bad boy cuts through your projects like a hot knife through butter. Righteous swell, bro.

Lets get down to it. I'd heard the hype: NodeJs is performant, non-blocking, and easy to learn. (See pretty much everyone at GluCon), and I'd also heard the jeers, Ted Dziuba, etc. (though 
I can't find any of their posts anymore, just mentions of them ... interesting)

var express = require('express'); var app = express();
var server = http.createServer(app).listen(app.get(3000), function() {
console.log('Express server listening on port ' + app.get('port'));
});

Boom!

I know it takes more than that ... but you get the idea. Nothing new there.

So I thought I'd try an example of an operation I hadn't seen a lot of floating around on the interwebz: Streaming new DB entries in realtime out to a page via WebSockets.

This is where it gets really interesting (at least it did for me) using MongoDB's streaming cursors, with capped data-collections. To create basically a one-stop message-queue real-time to web-socket buzzword orgy of awesomeness.

First define a schema in Mongoose, and add a tailable find:

var BidSchema = new Mongoose.Schema({
    price : { type : Number },
    amount : { type : Number } }, 
    { capped: { size: 5242880, max: 1000, autoIndexId: true }});

var Bid = db.model('bidSchema', BidSchema);

var bidStream = Bid.find().tailable().stream();

I ran into some issues at first when I tried this. 

MongoError: tailable cursor requested on non capped collection

BROTIP: THIS ONLY CAPPED COLLECTIONS CAN BE USED FOR STREAMING NEW RECORDS OUT OF MONGODB.

Next we setup a SocketIO to send our results out to the page as they are entered into the database:

var ioserver = require('socket.io').listen(server);
var clientsocket = null;

ioserver.sockets.on('connection', function(socket){
 clientsocket = socket;
 var timeout = null;
 
 bidStream.on('data', function (doc) { 
  clientsocket.emit('bid', doc);
 }).on('error', function (err) {
   console.log('error: '+err);
 }).on('close', function () {
   // the stream is closed
   system.debug('close');
 });
});

Next we setup our client-side, AngularJS Controller:

    script
      var socket = io.connect('http://localhost');

      function BidsController($scope, $http, $window){
        $scope.bids = [];

        $scope.save = function(bidForm){
          $http.post('/placebid', { bid : $scope.newBid }).success(function(response){
            console.log(response);
          });
        };

        $window.socket.on('bid', function (bid) {
          console.log(bid);
          $scope.$apply(function(){
            $scope.bids.push(bid);
          });
        });

      };

And our Jade Template display:

    body
    div(ng-controller="BidsController")
      h1 Enter a bid:
      form(name="bidForm", ng-submit="save(bidForm)")
        input.form-control(type="text", ng-model="newBid.price", name="price", placeholder="Enter a price.")
        input.form-control(type="text", ng-model="newBid.amount", name="amount", placeholder="Enter an amount.")
        input(type="submit")
      table(style="border:1px solid black;")
        tbody
          tr(ng-repeat="bid in bids")
            td(style="border:1px solid black;") {{bid.price}} 
            td(style="border:1px solid black;") ${{bid.amount}}

Bam. That was easy. Like I said...hot-knife through butter...!

Now your a full-stack developer, with plenty of time to go get stacked at the gym.

So get out there and get it brogrammer!

Source: Github here

PS. The whole "bro" thing was not a knock on the MEAN Stack - I've just been watching too much: Brosciencelife on youtube, that hitting the gym all week getting rock-swol for the Denver Triathlon. 

PSS. I'm still having trouble with the streaming cursor in mongoDB returning duplicates/triplicates of the same documents. I'll update if I figure it out, or someone comes along on stackoverflow.

T-Mobile Tethering w/ Google Chrome...or what the hack?

I've been tethering my rooted T-Mobile Android phones for over 2 years now. First I used the myTouch 4g, and more recently a Samsung Galaxy S3.

Recently, however, when connected to my T-Mobile Wifi Hotspot on my laptop, and browsing in Google Chrome my url requests are trapped and I'm redirected to a page like this:

This only seems to happened when browsing non-SSL (http) sites in Chrome and not when using SSL (https), as you can see from a similar request made immediately before this one to Github's SSL address:

Also, this doesn't seem to be happening in Firefox, Safari, or Opera when browsing via a T-Mobile tethered connection. So it begs the question? What is this voodoo? Is T-Mobile reading my Http requests and examining the user agent of the browser and redirecting me?* 

If so why wouldn't they redirect other desktop browsers? 

Furthermore, while I'm tethered, I typically start receiving PUSH messages from T-Mobile badgering me to upgrade to a paid tethering subscription. Again, unless the phone is sending some notification that it is using a tether back to the provider, I'm not sure how they are aware I am tethering.

Background:

Speed/Continued connectivity: Anyways, as I am well short of my monthly cap on bandwidth usage at 4G I haven't had any connectivity problems other than when I'm traveling at high-speeds in a car or train. The speeds are "OK" given my signal and amount of movement. There doesn't seem to be any attempt by T-Mobile to punish this transgression, on my bill or with my connectivity.

Device:

Samsung Galaxy S3 + Android 4.1.1 ROM based AOKP, I've used various ROMs that have tethering available. The most recent of which seem to keep the T-Mobile Hotspot management app, but others don't, and I've had the same issue.

So what is going on here? 

*This was an idea suggested by a colleague of mine after describing the problem. It would make sense, as it would be hard for them to capture the user-agent of an SSL encrypted request. This still begs the question about the other desktop browser user agents!