Security 101: Encryption, Hashing, and Encoding

Encryption, Hashing, and Encoding are commonly confused topics by those new to the information security field. I see these confused even by experienced software engineers, by developers, and by new hackers. It’s really important to understand the differences – not just for semantics, but because the actual uses of them are vastly different.

I do not claim to be the first to try to clarify this distinction, but there’s still a lack of clarity, and I wanted to include some exercises for you to give a try. I’m a very hands-on person myself, so I’m hoping the hands-on examples are useful.


Security 101: Beginning with Kali Linux

I’ve found a lot of people who are new to security, particularly those with an interest in penetration testing or red teaming, install Kali Linux1 as one of their first forays into the “hacking” world. In general, there’s absolutely nothing wrong with that. Unfortunately, I also see many who end up stuck on this journey: either stuck in the setup/installation phase, or just not knowing what to do once they get into Kali.

This isn’t going to be a tutorial about how to use the tools within Kali (though I hope to get to some of them eventually), but it will be a tour of the operating system’s basic options and functionality, and hopefully will help those new to the distribution get more oriented.

  1. KALI LINUX™ is a trademark of Offensive Security. 


Hacker Culture Reading List

A friend recently asked me if I could recommend some reading about hacking and security culture. I gave a couple of quick answers, but it inspired me to write a blog post in case anyone else is looking for similar content. Unless otherwise noted, I’ve read all of these books/resources and can recommend them.


Stop EARN IT and LAED

Unless you’ve been living under a rock, you know that the Crypto Wars are back. Politicians, seemingly led by Senator Lindsey Graham of South Carolina, seem bound and determined to undermine user’s privacy and security online to strengthen the power of the police state. It will have disproportionate affects on the innocent rather than criminals and will raise operating costs and make it much harder for small businesses and startups to compete in the US.

  1. Much like guns and nuclear weapons, the cryptography genie is already out of the bottle. Inserting backdoors or limiting access to encryption will affect law-abiding citizens, but criminals will be able to continue to use encryption software that already exists. In fact, the Al Qaeda terrorist organization already develops their own encryption software. It’s not like they’ll comply with US laws. While we might succeed in reducing their access to some types of encryption (e.g., encrypted phones), we won’t be able to completely eliminate it for motivated criminal enterprises or terror cells.
  2. There are a lot of legitimate reasons to want to use end-to-end encryption or full device encryption. Do companies want their sensitive data accessible to competitors? Do individuals want their data available to someone who finds their phone in a cab or steals it? Journalists want to be able to communicate with their sources in confidence, and attorneys and doctors should be able to securely encrypt their privileged files. The United States Senate even encourages Senators to use end-to-end encryption, as does the 82nd Airborne Division of the US Army.
  3. There is no such thing as good guy only access. Being good or evil is a matter of perspective and ethics, and technology does not recognize those. Any backdoor, key escrow, or other system designed to comply with these laws is subject to abuse by malicious governments, malicious insiders, or criminals. Cryptographer and professor Matthew Green says so, Bruce Schneier says so, and I say so. We’ve seen providers with stored keys breached before, so it would be pretty surprising if it didn’t happen again. The only way to keep the keys from being compromised is for the provider to not have them at all.
  4. It will decrease trust in American service providers. Look at the way Huawei and ZTE are treated because of potential Chinese backdoors. Why would another country want the US government to have a backdoor into communications they use? Even if you believe intent is good (and stopping child abuse is), the way the US government has used spying capabilities in the past raises serious concerns.

There’s good analysis on both EARN IT and LAED, the two bills introduced by Senator Graham here:

Based on EFF language, I wrote to my Senators and Representative the following:

I write you as both a constituent and in my personal capacity as an expert in cybersecurity. For most of the past decade, I have been employed as a senior security engineer at a large technology company, I have spoken at multiple conferences on information security, and have published articles on the matter..

I strongly urge you to reject both the EARN IT Act (S.3398) and the Lawful Access to Encrypted Data Act. They both pose an existential threat to online privacy and security.

End-to-end encryption protects innocent and law-abiding users against data breaches at their service providers. As we’ve seen time and time again, persons are irreversibly harmed when their communications are leaked, and requiring backdoor access for the government opens that backdoor to abuse by foreign governments and criminals.

The Graham-Blumenthal bill would give the Attorney General far too much power to dictate how Internet companies must operate. Attorney General William Barr has made it clear that he would use that authority to undermine our right to private and secure communications by blocking encryption. Additionally, passing on this power to the Attorney General leaves too much to the whims of each administration, resulting in a great deal of uncertainty regarding the future course of things.

The bill would create a commission tasked with creating “best practices” for owners of Internet platforms to “prevent, reduce, and respond” to child exploitation online. But far from mere recommendations, those “best practices” would be approved by Congress as legal requirements. The EARN IT Act’s structure would let Barr strong-arm the commission to include requirements that tech companies weaken their own encryption systems in order to give law enforcement access to our private communications. Companies could also be required to over-censor speech to comply with the government’s demands, or to bend to future governments’ political agendas in other ways.

Regulations relating to restrictions on speech must reflect a careful balance of competing policy goals and protections for civil liberties. Congress can only strike that balance through an open, transparent lawmaking process. It would be deeply irresponsible for Congress to offload that duty to an unelected commission, and especially not a commission controlled by unelected government officials.

Please publicly oppose the EARN IT Act and the Lawful Access to Encrypted Data Act.

I encourage you to do the same.


Private CA with X.509 Name Constraints

I wanted to run a small private Certificate Authority for some of my internal services. Since these aren’t reachable from the internet, and some of them are on network segments without internet connectivity, using a public ACME CA like Let’s Encrypt was inconvenient. On the other hand, if I run my own private CA and the keys get compromised, it could be used to MITM all my internet traffic. While that’s unlikely to happen, I decided to look for a better option.

It turns out that the idea of a “limited purpose” Certificate Authority is not new. RFC 5280 provides for something called “Name Constraints”, which allow an X.509 CA to have a scope limited to certain names, including the parent domains of the certificates issued by the CA. For example, a host constraint of .example.com allows the CA to issue certificates for anything under .example.com, but not any other host. For other hosts, clients will fail to validate the chain.

This hasn’t always been supported by TLS libraries and browsers, but all current browsers do support Name Constraints. Consequently, this is an approach to narrow the risks associated with a CA compromise for hosts other than those covered by the constraints in the CA certificate.