Taaza Vaartha: Encryption

Showing posts with label Encryption. Show all posts

Using Vault to Manage Your App’s Secrets

Get latest online news, taaza, breaking news updates, political, business, entertainment, movies, music, national, international, state news.

Vault is a new tool for managing and encrypting your app’s secrets. It can be used to keep everything from your API tokens, to your database passwords, safe and secure. Historically, secret management has been a very involved process, and it was far too easy to inadvertently introduce security issues. Vault is here to make this process simpler. Here are eight reasons why Vault is worth considering for your next project.

1. It’s Stack Agnostic

Storing secrets has long been a platform-specific affair, with little carry over between technology stacks. You might use secrets.yml for your Rails projects, but that doesn’t help you with your Node projects. More often then not, though, developers end up rolling their own ad hoc solutions for managing secrets. Vault can be used across all technologies in your stack, and prevents you from having to constantly reinvent the wheel.

2. It’s by the Brains at Hashicorp

Hashicorp has been providing amazing open source tools for some time now. Packer, Serf, Consul, Terraform, and the very popular Vagrant, are all impressive tools. Granted, a history of great products doesn’t guarantee all future products, but there is definitely every reason to believe in Vault, given Hashicorp’s prior successes.

3. Environment Variables can be Painful

Storing your configuration outside of your code is one of the pillars of a 12 factor app. The gold standard for this has been environment variables. While a workable solution, they do have some baggage that comes along with them. One is that, while it’s fairly manageable to control which environment variables are exported in a given environment, it is harder to guarantee the absence of other variables. Another issue is the global nature of environment variables can make them somewhat unpredictable. Vault lessens your dependency on environment variables by allowing you to store such configuration data in their key value system instead.

4. It’s Battle-Tested

While it’s new to the outside world, Vault has been running at production scale over at Hashicorp for sometime now. The source code for Vault is readily available for inspection over at Github, and it can be verified that Vault has some strong test coverage. This isn’t some hacked together weekend project.

5. It Makes a Lot of Sense With a Microservices Architecture

Vault meshes very nicely with microservice-based architectures. I’ve made a few projects with Vault, and having all my components talk to one service that handles credentials — and handles only credentials — made a lot of sense. In microservice-based architecture, you’ll have a service for your mailing, for your front-end, for order processing, etc … so why not have one service that handles all of your secrets? All of your other services can get their credentials through Vault’s REST API, and you won’t have to encode secrets into any other of your services. This is a pretty big win.

6. Dynamically Generated Credentials

It’s a common practice to issue credentials on a per user basis, instead of sharing one set of credentials across all users. The logical next step is to issue credentials on a per transaction basis. These dynamically created credentials can be revoked immediately after completing your transaction. This provides an even greater promise that your credentials won’t be compromised, and provides even further damage mitigation in the unlikely event of a breach.

7. Clean API

Vault is very well thought out; it hits that rare combination of being simple to use and understand, without limiting its power or use cases. In my experience, it doesn’t take long to go through the docs/tutorials, and quickly start feeling like a Vault power user.

Caveats

While all the above is great — as is typically the case with software — certain tradeoffs were made in Vault’s design, and there are some limitations. While there are many benefits to being able to run Vault as a service, this does lead to increased infrastructure costs, and the associated pains of managing that infrastructure. Additionally, not all of Vault’s benefits are available for all use cases. For example, dynamically generated secrets can only integrate with a limited number of other services. Also, Keywhiz by Square is another big player in this area that is worthy of attention. The biggest fundamental difference between Vault and Keywhiz, is that while Vault exposes secrets over an API, Keywhiz uses a FUSE filesystem. Vault wrote a nice and fairly objective writeup on the comparison. Lastly, if you are working with Chef or a related tool, it’s probably easier initially to use their integrated solution than it is to wire it up to Vault.
Revolutionary new technology is often revered with with a combination of awe and trepidation. While it makes sense to be cautious about adding new things to your tech stack, vault has a very compelling use case in an underserved area of computing. Give it a go for your next project; however, there’s a good chance you’ll be tempted to migrate all of your projects over to vault later. For those who are interested, be sure to checkout the official Vault tutorial.

AES Encryption Technology

Advanced Encryption Standard (AES)

Taaza Vaartha at 15:22 0

Get latest online news, taaza, breaking news updates, political, business, entertainment, movies, music, national, international, state news.

The Advanced Encryption Standard or AES is a symmetric block cipher used by the U.S. government to protect classified information and is implemented in software and hardware throughout the world to encrypt sensitive data.

The origins of AES date back to 1997 when the National Institute of Standards and Technology (NIST) announced that it needed a successor to the aging Data Encryption Standard (DES) which was becoming vulnerable to brute-force attacks.

This new encryption algorithm would be unclassified and had to be "capable of protecting sensitive government information well into the next century." It was to be easy to implement in hardware and software, as well as in restricted environments (for example, in a smart card) and offer good defenses against various attack techniques.

Choosing AES

The selection process to find this new encryption algorithm was fully open to public scrutiny and comment; this ensured a thorough, transparent analysis of the designs. Fifteen competing designs were subject to preliminary analysis by the world cryptographic community, including the National Security Agency (NSA). In August 1999, NIST selected five algorithms for more extensive analysis. These were:

MARS, submitted by a large team from IBM Research
RC6, submitted by RSA Security
Rijndael, submitted by two Belgian cryptographers, Joan Daemen and Vincent Rijmen
Serpent, submitted by Ross Andersen, Eli Biham and Lars Knudsen
Twofish, submitted by a large team of researchers including Counterpane's respected cryptographer, Bruce Schneier

Implementations of all of the above were tested extensively in ANSI, C and Java languages for speed and reliability in encryption and decryption, key and algorithm setup time, and resistance to various attacks, both in hardware- and software-centric systems. Members of the global cryptographic community conducted detailed analyses (including some teams that tried to break their own submissions).
After much enthusiastic feedback, debate and analysis, the Rijndael cipher -- a mash of the Belgian creators' last names Daemen and Rijmen -- was selected as the proposed algorithm for AES in October 2000 and was published by NIST as U.S. FIPS PUB 197. The Advanced Encryption Standard became effective as a federal government standard in 2002. It is also included in the ISO/IEC 18033-3 standard which specifies block ciphers for the purpose of data confidentiality.
In June 2003, the U.S. government announced that AES could be used to protect classified information, and it soon became the default encryption algorithm for protecting classified information as well as the first publicly accessible and open cipher approved by the NSA for top-secret information. AES is one of the Suite B cryptographic algorithms used by NSA's Information Assurance Directorate in technology approved for protecting national security systems.
Its successful use by the U.S. government led to widespread use in the private sector, leading AES to become the most popular algorithm used in symmetric key cryptography. The transparent selection process helped create a high level of confidence in AES among security and cryptography experts. AES is more secure than its predecessors -- DES and 3DES -- as the algorithm is stronger and uses longer key lengths. It also enables faster encryption than DES and 3DES, making it ideal for software applications, firmware and hardware that require either low-latency or high throughput, such as firewalls and routers. It is used in many protocols such as SSL/TLS and can be found in most modern applications and devices that need encryption functionality.

How AES encryption works

AES comprises three block ciphers, AES-128, AES-192 and AES-256. Each cipher encrypts and decrypts data in blocks of 128 bits using cryptographic keys of 128-, 192- and 256-bits, respectively. (Rijndael was designed to handle additional block sizes and key lengths, but the functionality was not adopted in AES.) Symmetric or secret-key ciphers use the same key for encrypting and decrypting, so both the sender and the receiver must know and use the same secret key. All key lengths are deemed sufficient to protect classified information up to the "Secret" level with "Top Secret" information requiring either 192- or 256-bit key lengths. There are 10 rounds for 128-bit keys, 12 rounds for 192-bit keys, and 14 rounds for 256-bit keys -- a round consists of several processing steps that include substitution, transposition and mixing of the input plaintext and transform it into the final output of ciphertext.

As a cipher, AES has proven reliable. The only successful attacks against it have been side-channel attacks on weaknesses found in the implementation or key management of certain AES-based encryption products. (Side-channel attacks don't use brute force or theoretical weaknesses to break a cipher, but rather exploit flaws in the way it has been implemented.) The BEAST browser exploit against the TLS v1.0 protocol is a good example; TLS can use AES to encrypt data, but due to the information that TLS exposes, attackers managed to predict the initialization vector block used at the start of the encryption process.
Various researchers have published attacks against reduced-round versions of the Advanced Encryption Standard, and a research paper published in 2011 demonstrated that using a technique called a biclique attack could recover AES keys faster than a brute-force attack by a factor of between three and five, depending on the cipher version. Even this attack, though, does not threaten the practical use of AES due to its high computational complexity.

Pages

Taaza Vaartha