Tag: encryption

Introducing MKISIO

Roundabout a year ago yours truly sought out “substitute” for this blog. I desired the ability to “post” information to content consumers, much as is done with websites, except I wanted the content delivered direct. Use an email newsletter service. Voila! There are tons of those around. Easy!

That is a fact. There are plenty of email newsletter service providers already in business. Some are free, and others even allow you to charge for your newsletter. I was looking for both options, but I also wanted the ability to encrypt newsletters with OpenPGP and provide subscribers with a way to read the stuff without having a degree from MIT (i.e. install crazy complex software); I thought it would also be nice to have some protection for both myself and potential subscribers in case of a security breach. As the latter goes, nothing but NOTHING is un-hackable, so why not make the stored data completely useless to miscreants?

I simply could not get this combination of features from anything in the wild, so I built it myself (with a little help of course). It is called MKISIO.

After covering the basic requirements some additional fun stuff was added, including …

  • Optional invitation functionality – so a publisher can ensure only known peeps are subscribing to their newsletter
  • Shortlink and QR code quick subscribe widgets – for plastering on legacy blogs and social media profiles
  • Subscription clearinghouse – as new publications are started, anyone with an account can find them and subscribe (assuming they are not invitation-only)
  • A couple of aces and kings up a sleeve, guaranteeing consistent performance in Hold ‘Em

As to the why this concoction was dreamed up in the first place, well the folks over at ReclaimTheWeb have the skinny on that. It wasn’t about creating a solution for raw censorship or economic hardball a.k.a. de-platforming though; I just wanted something that could afford more privacy and security, thereby making free speech the default. Sure, if someone wants to share confidential information via a MKISIO newsletter, they most certainly can use the encryption functionality. That was part of my original wish list, if only because nobody was doing it. Call it a personal challenge, successfully tackled. But the system is also good for sharing treasured fruitcake recipes, keeping extended family up-to-date on the kiddos report cards, or castigating members of the condo association … without fear of “repercussions”.

Meanwhile, I will be writing what otherwise would get posted here, over there. You can subscribe to my newsletters by clicking this link. Alternatively, feel free to point your phone camera at the nifty QR code to the left (that is if you are not already reading this post on it).

End Note: If you’ve read all of the above technical jargon slash carefully crafted PR and are still wondering where the name came from because you thought “MKIS” stood for Marketing Information Systems (you are correct), just read this (warning: it’s silly, but almost the truth). Finally, don’t forget that the beast is still work-in-progress, so if you decide to play and find a problem please feel free to let me know.

MG signing off (to blog via email for a while)

Quick fix for the phpseclib -> BigInteger choke on macOS 10.14

This will be quick.

You are tooling with phpseclib on macOS. You try generating some hefty, say 4096 bit keypairs and BigInteger times out after 60 seconds. WTF do you do?

Well, BigInteger.php will leverage OpenSSL and/or bcmath for this kind of stuff, but it seems it gets a migraine after 2048 bits. It’ll charge after mcrypt and gmp too, if they are available, but neither is in macOS’s default PHP. We’ve covered mcrypt in the recent (and many days) past, and I had it and libsodium installed on my “device” when I filled an Apache error log up with fatals. Hence I looked to get gmp running.

It’s a relatively simple process … first gather all the items listed in this post on installing mcrypt. Then, you are going to follow some simple steps.


Installing libsodium for PHP on macOS Mojave 10.14

While mcrypt installation has been the subject of [developer] fits and [yours truly’s] restarts, mcrypt is in fact going away. libsodium is the new player in town, a point I anticipated long ago being the venerable tech expert that I am just found out being the accountant who unfortunately bears the burden of having used dBase and Paradox in a past life.

That said, the process is relatively similar to mcrypt i.e. you will need brew (and I suggest XCode command line tools, just in case). Instructions for both are readily available via the only hyperlink in the paragraph immediately proceeding this one. Further, you need not bother with PHP source, but you might as well turn off SIP beforehand. Now let’s get started.


A Public Key Infrastructure for Extensible Interoperability

An explanation for that title is in order. It is the culmination of what I call my “dark side”. Literally.

Eighteen months ago a colleague and I embarked on a brain-busting adventure: figure out a way to encrypt anything (or everything) on the web without installing any software – full-on security for the cloud. A few months later CryptML, an entirely new markup language whose sole purpose is hard encryption, was born. Since that time we’ve been developing a representative sample implementation, debugging more code than any human being should ever have to, and building an entire platform around what started as satisfaction of intellectual curiosity.

Could it be done? You betcha! We’re now working straight out of the National Security Agency’s playbook, using a collection of algorithmic components called Suite B. And we’re doing so without violating any patents.

While a few folks out there pass by these pages looking for help with mcrypt and Wireshark, most come by to hear about fly fishing. I’d like to keep it that way, so I won’t bore you with the extraneous details. Nevertheless, a paper I wrote recently outlining some of the history of modern encryption and why I feel it is in the best interests of both the general public AND national security to adopt technology such as ours, was picked up by Military Information Technology Magazine, and published in their April edition. Needless to say we’re pretty happy about that, and we greatly appreciate MITM’s consideration of what we’ve accomplished.

The introduction from that paper follows, and for those really interested a link to the entirety over at the MITM website has been included below too.

The existing public key infrastructure was developed in the late 70’s and early 80’s as part of research coming out of academia. The systems and methods were quickly perceived as a revolutionary way to satisfy the secure data exchange needs of the scientific community, and later the federal government. Since that seminal period, advances in microcomputer technology have pushed communication channels, protocols, and hardware to the point where the convergence of voice, video and data are the norm. Secure communication using encryption, however, is still based on standards developed in decades past, with advancement centering primarily on new algorithms to replace those for which mathematical weaknesses are found.

Unfortunately, it is the seemingly never-ending advancement of computing horsepower combined with its ever-falling prices that are enabling the discovery of the “flaws”. Unless computational speeds unexpectedly plateau, the costly cycle of adopting new platforms and devices to replace those built on ever weakening encryption schemes will continue unabated.

What is needed is a completely new paradigm for the process of encoding, exchanging, decoding, and validating data – one that can completely replace that built for the closed-loop, point-to-point communications existing before internet protocol (IP) use became pervasive.

The rest of the piece can be found here: http://www.military-information-technology.com/mit-archives/241-mit-2010-volume-14-issue-3-april/2793-public-key-infrastructure-for-interoperability.html – Public Key Infrastructure for Interoperability. If the link doesn’t work, just pick up a hard copy – available in the lobby of the Pentagon.

Special thanks go out to editorial staff at MITM, as well as other individuals who helped make this happen. If you are in the defense, healthcare information systems, or financial services fields and are interested in seeing our representative application, a hard-encrypted messaging tool, you can contact us here for an invitation.

UPDATE 10/12/16: The link above is no longer in service. Hence the entire text of the original article has been reproduced in its entirety below.


This article originally appeared in Military Information Technology 14.3.


The existing public key infrastructure was developed in the late 70’s and early 80’s as part of research coming out of academia. The systems and methods were quickly perceived as a revolutionary way to satisfy the secure data exchange needs of the scientific community, and later the federal government. Since that seminal period, advances in microcomputer technology have pushed communication channels, protocols, and hardware to the point where the convergence of voice, video and data are the norm. Secure communication using encryption, however, is still based on standards developed in decades past, with advancement centering primarily on new algorithms to replace those for which mathematical weaknesses are found.

Unfortunately, it is the seemingly never-ending advancement of computing horsepower combined with its ever-falling prices that are enabling the discovery of the “flaws”. Unless computational speeds unexpectedly plateau, the costly cycle of adopting new platforms and devices to replace those built on ever weakening encryption schemes will continue unabated.

What is needed is a completely new paradigm for the process of encoding, exchanging, decoding, and validating data – one that can completely replace that built for the closed-loop, point-to-point communications existing before internet protocol (IP) use became pervasive.

A brief explanation of key-based encryption

Key-based encryption generally falls into two categories – symmetric and asymmetric – and both are actually fairly simple concepts when the mathematics is removed from the description. Under symmetric encryption, there exists a single key that both “locks” and “unlocks” the data – both sender and receiver share that key before the data is transferred. In asymmetric encryption, two keys are required: one is used to encrypt (lock) the data, and is readily shareable by all participants, while another key is used to decode (unlock) the data.

With symmetric encryption, if sender and receiver want to keep communications between themselves alone the connection must remain secure, particularly during the key sharing process. For this reason, symmetric encryption is most suitable for point-to-point networks such as those historically deployed in the military theatre. Asymmetric encryption, however, doesn’t require this pre-determined, ongoing trust. A party wishing to receive, say simple text messages, simply generates a publicly available key for encrypting those incoming messages, and can do so far in advance of the discrete communication. It is then distributed to everyone the potential data recipient needs to receive communications from, and that receiver is ultimately responsible for keeping it up to date. The secret, or private, key is the only key that can decode any inbound communications, and is generally kept secure by that recipient. Asymmetric encryption also allows other users to validate those self-generated keys, as well as determine when they are legitimately changed.

Origin of today’s standards

In 1976 Whitfield Diffie and Martin Hellman published a paper entitled New Directions in Cryptography that specified an innovative method for key exchange. The process allowed communicators with no prior knowledge of each other to establish a shared key without the need for a secure network. While a number of cryptosystems have been developed since, Diffie-Hellman has become the de-facto standard for key exchange, and part of the foundation of the public-key encryption in wide use today.

The National Security Agency adopted an improved derivative of Diffie-Hellman and married it with algorithms used for other parts of encrypted communications, forming a set of standards called Suite B. The openly published Suite B includes specifications for encrypting data, exchanging keys, signing messages, and validating received data.

Suite B’s base elements and the Federal Information Processing Standards they are derived from are as follows:

– Encryption: Advanced Encryption Standard (AES) – FIPS 197 (with key sizes of 128 and 256 bits)
– Key Exchange: Elliptic Curve Diffie-Hellman – Draft NIST Special Publication 800-56 (using the curves with 256 and 384-bit prime moduli)
– Digital Signatures: Elliptic Curve Digital Signature Algorithm – FIPS 186-2 (using the curves with 256 and 384-bit prime moduli)
– Hashing: Secure Hash Algorithm – FIPS 180-2 (using SHA-256 and SHA-384)

Announced in early 2005, Suite B complies with policy guidance set out by The Committee on National Security Systems, and can be used for encrypting information up to a level of Top Secret when the larger bit-sized keys are used.

The Suite B specification has been submitted to the Internet Engineering Task Force (IETF) for inclusion in Internet Protocol Security (IPSec), a budding framework for securing data at the packet layer. IPSec is designed to encrypt all traffic crossing the internet, either by securing the individual package being sent (transport mode) or by securing the actual route the data is sent over (tunnel mode, or virtual private networking). The latter methodology is in widespread commercial and governmental use today, but it suffers from many of the same limitations the underlying encryption infrastructure does.

Inherent weaknesses of the existing model

The existing model has aged. It was created while the personal computer was still in its infancy, and when widespread access to networks did not exist. Development burgeoned when the environment was simple, and the user base sophisticated. The surrounding conditions are now infinitely more complex, and the average user less so.

Encryption technology was developed before 3MHz desktop CPUs were commonplace – 3GHz is now a norm – and internet connections, if available at all, were at best dialup speeds. Hence, the approach to implementing it meant minimizing the processing requirements as well as minimizing the amount of data that had to be transmitted. The tradeoff was that software was inflexible, provided minimal features, and was difficult to update. What might have seemed like fair compensation for performance then is insignificant, maybe even a nuisance, today. Concerns about encryption overhead should now be relegated to only the most demanding applications, particularly across networks whose capacity has expanded a billion-fold or more since the 1970s.

Variants of Suite B are already used in a variety of hardware and software applications, but most are fixed with respect to the platform. In other words, change is hard to come by. If a computer scientist (a.k.a. hacker) is able to find a weakness in just one portion of the mathematics that are part of Suite B, entire systems must be changed for future security to be ensured. For example, the MD5 hashing algorithm was “cracked” in 2004, yet many systems, including the Secure Sockets Layer (SSL) certificate exchange that is the foundation of internet commerce, are still using MD5 because of the widespread switching costs that would result.

Existing key-based encryption works within an infrastructure that is relatively transparent to the sophisticated user. For those that are not extensively trained, however, even installing and properly configuring a desktop email client encryption plug-in can be an impossible task. Users must learn how to generate random key data, must know how and/or where to obtain an encryption key pair, must know how to generate a revocation certificate to change those keys, and must quickly comprehend complex web-of-trust issues before they can safely communicate in a secure environment. Further, varying commercial software products contain components of encryption functionality, but such features are often de-emphasized both in the product and in the documentation. Stand-alone encryption software is much the same, and usually requires support in the form of a full-fledged systems administrator to operate.

Network in transition

While development of the public-key infrastructure remained relatively stagnant, the growth of the internet as public medium pushed forth – and was pushed forth – by new protocols and languages. New communication standards were formed for the exchange of different data types, including:

– iLBC and G.711 for voice
– MPEG-4 and H.264 for video
– HTML and XML for text and data

These standards centered on usability and interoperability. Hardware and software manufacturers adopted them because the general public, the consumer market critical to their economic growth, could utilize them easily, and the protocols could be delivered with chosen measures of opacity. Newer, more sophisticated applications were developed on and around them.

The first email was sent in 1971 – less than a decade later public-key encryption entered its present stage. Meanwhile, in 1989 Tim Berners-Lee gave us the World Wide Web, and a few years later the browser was born. Core processes for delivering secure data may be relatively unchanged, but we now have streaming video on cellular phones to deal with. As data processing moves ever closer to the fully-distributed cloud computing model, leveraging the combination of open standards and tools built first for usability makes perfect sense both technologically and economically. Encryption schemes need to follow the same path, that of interoperability and extensibility.

Re-engineer the entire infrastructure

Adopting a new infrastructure for secure data exchange works for one simple reason: the rest of the network has already moved far past what exists today. Governmental bodies have already begun implementing Commercial Off-The-Shelf (COTS) hardware into newly deployed systems. In most cases this hardware is already fully capable of interfacing with web services.

Embracing the base technology behind the commercial internet provides the ultimate in interoperability. Browsers, for example, are virtually omnipresent – and they can run on almost any hardware. In fact, much of the COTS network equipment utilized by the US military already contains browser software for configuration and management. By extension all devices deployed in the theatre, whether it is baseband hardware, reachback equipment, or remote connections via handheld device, could be exchanging data via the same web services, and with little or no additional customization.

The World Wide Web was designed for constant change, hence the tools that interpret the data must be able to constantly adapt. Unlike the present encryption infrastructure, a new model is already available that can not only manage key exchange from point to point or amongst multiple users in disparate locations, but can also obtain keys from a variety of sources (include those under physical control) and orderly or arbitrarily switch those sources as security procedures require. Further, applying web technologies to encryption services allows the user to update those services to keep up with changing mathematics. If an algorithm presently in use is deemed insecure, it can be replaced with another one immediately. Should the system user determine that interchanging algorithms in the middle of a conversation is necessary to comply with the classification of content being exchanged, it can be done on-the-quick-halt instead of after a new hardware requisition.

Web services are also designed to be interoperable not only with hardware, but also with software. While internet browsers are the de-facto standard for accessing web services on the public internet, many application front-ends are ported to client-side software. This provides additional security in the form of source code audit-ability. In addition, users gain added control over access to virtual private networking services, certification, and other layers of security outside the realm of commercially available and/or open source software. A well-engineered service can be access via proprietary software, without degrading either performance or the flexibility web services are known for.

Beneficial change

The free exchange of data across IP networks is not going away. Once ubiquitous, which it arguably already is in all but developing countries, those connected will find ever-expanding ways to leverage it. Encryption technology must already make a generational leap just to catch up.

Adopting a web services approach to a new encryption infrastructure has several distinct advantages:

1) Usability – the growth of the commercial internet is proof-of-concept, now a mainstay of day to day voice, video and data exchange, including commerce that is a measureable portion of gross domestic product;

2) Flexibility – as data exchange needs change, the platform is quickly modified to comply with those needs with virtually no additional effort or costs – changes can also be made on-the-quick-halt;

3) Interoperability – web-based technologies run on networking hardware, personal computers, cellular telephones and other devices very efficiently; web-services can operate seamlessly with new systems as well as hardware and software already deployed in the field; and most importantly…

4) Security – encryption as a web service means state of the art defense against intrusion; combining it with existing standards such as Secure Sockets Layer and Virtual Private Networking makes it even more so.

The cost versus benefit applied to encryption schemes is insignificant. Training happens quickly, even at the individual non-technical personnel level, because familiarity with the required tools is an afterthought. All equipment deployed in the field utilizes the same technology, resulting in multiple-mission capability – overall hardware needs are significantly reduced. And finally, as the base mathematics behind encryption are deemed inferior for the data they are to secure, new algorithms can replace the old immediately, versus recalling all equipment for update or dispersing technical expertise into the field to perform the task.

It is time to implement the next generation of encryption delivery, to ensure data security network-wide, permanently applied against the foreseeable future.


I like my cookies with encryption on top

Quick and dirty mcrypt usage

I don’t know where I discovered the original idea, but in messing around with a PHP app I found the need to encrypt session cookies. Here’s how it was done, with the mcrypt library:

//encrypt session cookie
function encryptUserCookie($value)
if(!$value) {
return false;
$text = $value;
$iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
$iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
$crypttext = mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $key, $text, MCRYPT_MODE_ECB, $iv);
return trim(base64_encode($crypttext)); //encode for cookie

Decoding the cookie was much the same…

//decrypt session cookie
function decryptUserCookie($value)
if(!$value) {
return false;
$crypttext = base64_decode($value); //decode cookie
$iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
$iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
$decrypttext = mcrypt_decrypt(MCRYPT_RIJNDAEL_256, $key, $crypttext, MCRYPT_MODE_ECB, $iv);
return trim($decrypttext);

SESSION_SALT was of course something I called from a variables file.

These snippets were used in an online directory system, where I didn’t want attendees inspecting the cookies for the purpose of setting up multiple listings under the same login.

Simple stuff, but hope it is useful to someone.

How not to store your keys

Bruce Schneier, on learning that some health care works stored encrypted information on a USB memory device, along with the key to unlocking the encryption itself:

It’s smart to encrypt USB memory devices, but it’s stupid to attach the encryption key to the device….I’m sure they were so proud that they chose a secure encryption algorithm.

For those just joining, the above described action is the approximately equivalent to this…


Editor’s note: the picture above is neither a good Photoshopping job nor an accurate depiction of the author’s rear bumper.

Crossing Borders with Laptops and PDAs

Bruce Schneier recommends a good cleaning and PGP (or TrueCrypt).

More on PGP here. I also use Cache Out X for clearing internet and system caches, as well as system logs.

Researchers Find Way to Steal Encrypted Data

Sadly, the headline is somewhat amiss.

Researchers have actually figured out a way to steal data from hard disks which are encrypted in full by operating systems’ resident protection schemes. In other words, I don’t believe this method would work on file/container encryption with passphrases (which happens to be my personal preference).

Nobody listens to the White House

After the Veterans Administration wrote the script for downplaying risk, when tens of millions of data records were stolen out of an employee’s home, the Bush Administration issued an edict – encrypt all data on government laptops.

Good idea, but nobody’s listening. Wonder what the TSA’s “100,000” number will grow to?

Data security experts…Ohio won’t be calling (any moment)

I wish I could say I am shocked and bewildered that the recent data theft out of the State of Ohio was more than 15 times worse than Ted Strickland & Co. made it out to be when the physical drive (?) was stolen out of an employee’s car, but alas I cannot. I wish I had a more sarcastic way to put it too, but Carlo over at Techdirt did a pretty good job of that. Meanwhile, I’ve recently heard that sarcasm is symptomatic of passive-aggressive behaviour, and since an old girlfriend once told me I was the only man she ever dated that wasn’t “PA,” I’m going to respect her opinion and refrain from sarcasm from this day forward.

Ok, maybe not…

It’s not as though Ohio didn’t see this coming – it’s been going on in the Buckeye state for some time. Then again, does anyone in bureaucracies ever know what is actually going on? If they did, would they even care? Or are they just so attuned to stretching the truth that they just don’t know how to shut up, even in the face of stone cold evidence waiting to rear it’s ugly head?

No matter. When the “powers that be” come out with statements like this:

“He’s actually in line with our conclusions that it would be very difficult for someone without special knowledge and understanding to actually access that piece of information.”

…you know someone is speaking for someone else right before they get handed their pink slip. “Very difficult?” “Special knowledge?” The spokesperson is either completely insane or oblivious to the fact that there are third world countries full of brilliant mathemeticians, since cast into the shadows of unemployment and looking feverishly for work on internet message boards.

The same types of folks create stuff like this:

Add this:

And wind up with this:

And that’s for a few hundred bucks, based on some handwritten notes a moron like me scratches on the back of an envelope over three Blue Moon drafts, and faxes over to him at his office at the local community college. I use such strokes of amatuerism to create graphs on a very stupid, highly unsuccessful website I built for a few thousand bucks more.

If I can rally such idiots to produce algorithms at a price equal to a steak dinner in New York proper, for something I will never see a return on my investment for, you can be assured that there is someone out there that can crack the encryption on a device left in the back of a government clerk’s car that contains social security and bank account numbers on a million people, just for throwing in a bottle of 1999 Chateau Pichon Lalande.

UPDATE: None of this matters anymore – a scapegoat has been caught, tried, and hung. That’s how it works.