If the key and seed remain unchanged, will the encryption/decryption always yield the same results, and do so regardless of the machine on which the algorithm implementation is executing? A value encrypted on a desktop can be decrypted on a server or on another desktop (as long as the key and seed are known)? Changes in server security certificates, etc are irrelevant?
Yes, the AES algorithm is standardized and the machine used has no influence on the result of the encryption. Knowing the seed, the key and the chaining-mode used any computer can decrypt an encrypted message.
Regarding your second question certificates are used with asymmetric encryption (algorithms like e.g. RSA) and are therefore not relevant to AES which is a symmetric algorithm.
Related
We are implementing encryption at rest in Kubernetes by this tutorial (https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) and we are absolutely not sure why AES-GCM encryption provider requires to rotate the key every 200K writes, because of lack of knowledge about how encryption works. Also, what exactly means: "200K writes", how can we define that we should rotate the key? Thank you
we are absolutely not sure why AES-GCM encryption provider requires to rotate
The GCM mode is basically a CTR streaming mode with built-in integrity validation (message authentication code). For this mode is very important to prevent reusing the same IV/key pair. It is advised to limit amount of the content encrypted with the same key limiting probability of the nonce-collision and options for key analysis (these is some math behind, already referred in the comments).
Yes, 200k is an arbitrary number, but someone has to state a reasonable number where nonce-collision probability is still negligible and the key is usable for significant time.
what exactly means: "200K writes",
This is usually very hard to estimate, depending what is the "write". It may be different if you use the key to encrypt other random keys (as a wrapping key) or the key is used to encrypt a lot of continuous content (e.g. a storage).
how can we define that we should rotate the key?
Let's be practical, e.g. AWS KMS provides automatic key rotation every year. Based on the question, assuming the key is used to encrypt the etcd storage (configuration), a yearly rotation can be a safe option. (I expect you don't have 200k secrets and config maps in the k8s cluster).
The key rotation process usually creates a new key (key version) and new content is encrypted using a new key. The existing content is still possible to decrypt using the older keys.
In this regard I have a little concern about how the key rotation is described in the documentation. Basically the steps 1-4 look ok, a new encryption key is defined and put in force. The step 5 and 6 are to re-encrypt all the etcd content using the new key basically limiting (if not defying) the whole purpose of the key rotation. Maybe you could pick that up with the support if you have time and patience to dig in.
As per OpenShift docs:
https://docs.openshift.com/container-platform/3.11/admin_guide/encrypting_data.html
Kubernetes has no proper nonce generator and uses a random IV as nonce for AES-GCM. Since AES-GCM requires a proper nonce to be secure, AES-GCM is not recommended. The 200,000 write limit just limits the possibility of a fatal nonce misuse to a reasonable low margin.
It's just an arbitrary number from what I can see.
How can I Decrypt the code which is Encrypted by md5 method in PostgreSQL.
eg: md5("logesh") returns '82e05c4839aba7c637881489bec50dd1'
How can I decrypted this code.
You can't. MD5 isn't encryption. It's a one-way cryptographic hash function. With enough compute power and/or storage you can brute force md5 to figure out what the plaintext might have been but it's only one possible plaintext for that hash. It's designed to be both slow and difficult to reverse, and impossible to reverse 1:1. There are known MD5 collisions.
PostgreSQL's use of "encrypt" in WITH ENCRYPTED PASSWORD is somewhat incorrect, it should really be WITH HASHED PASSWORD. But too late to change it now.
If you want encryption look into pgcrypto which offers AES-128 routines, etc. Or do your encryption and decryption client-side where key exposure in logs, pg_stat_statements etc isn't such a concern.
I have oracle database to move on to new postgresql server.
Some tables are having field sesitive and those are all encryted through DBMS_OBFUSCATION_TOOLKIT.DESENCRYPT/DESDECRYPT.
The problem is here. The size of postgresql's encrypted data size(bytea type) should be the same with oracle's.
I tried to get it done with aes(encrypt/decrypt) which takes almost three times larger than raw data.(oracle takes 16byte with des algorithm, postgresql takes 33byte with aes and the raw data is of 13byte.)
I tried the postgresql crypt also, but the manual doesn't metion the way of decrypting it back limiting 8byte of raw data size.
Now i really need encrypt method which takes as small encryted data size as possible and provides decrypt method also.
Is there a good way or the other options for me???
Thanks in advance.
Crypt and DES are old cyphers and should not be used
Plain old DES is an obsolete algorithm. You can't really usefully compare it to AES128; it's like complaining that a SHA256 hash is bigger than an MD5 hash - yep, it is, but only one of them might slow the attacker down for a while. DES was widely considered weak even in 1999 and should never be used in new applications. Do not use it.
I don't think it's a good idea to seek an encryption method that "provides the smallest data size possible" - because it's basically a waste of time to encrypt data using DES. Why not use ROT13 (caesar cypher)? The "encrypted" result is the same size as the input, pity the encryption can be broken by a 3-year-old.
crypt is of a similar vintage. The old UNIX crypt hashing algorithm is ... elderly ... and totally unsuitable for any new application. Hashes should be SHA256 at minimum, really.
Crypt is a one-way hash
As for not being able to figure out how to decrypt crypted data: crypt isn't an encryption algorithm, it's a cryptographic hash function or "one way hash". One way hashes are suitable for verifying that data is unmodified, comparing to a stored salted hash for password authentication, for use in challenge-response authentication, etc. You cannot decrypt crypted data.
Deal with the size
Use a decent cryptographic function and live with the size increase. bf or aes128 are about the weakest you can reasonably use.
Personally I prefer to do my encryption/decryption in the app, not in the DB. If it's done in the DB the keys can be revealed by pg_stat_statements, in the logs by log_statement or errors, etc. Better that the key never be in the same place as the stored data at all.
Most programming languages have good cryptographic routines you can use.
It's hard to offer any more advice as you haven't really explained what you're encrypting, why, what your requirements are, what the threat(s) are, etc.
Passwords?
If you're storing passwords, you're probably doing it wrong.
If possible, let someone else do the authentication:
OAuth or OpenID for Internet
SSPI, Kerberos/GSSAPI, Active Directory, LDAP bind, SASL, HTTP DIGEST, etc for intranet
If you really must do the auth yourself, add a salt to the passwords and hash the result. Store the hash and the salt. When you must compare passwords, salt the new plaintext from the user with the same salt you used for the stored hash, hash the new password+salt, and see if the hash is the same as what you stored. If it is, they gave the right password.
You almost certainly don't need to recover cleartext passwords. Implement a secure password reset instead. If you really, really must, use a decently secure algorithm like aes to encrypt them and think carefully about key storage and management. See other posts on SO about key storage/management with pgcrypto.
See also:
Secure method for storing/retrieving a PGP private key and passphrase?
Depending on how your postgresql was built, it may have DES support in the pgcrypto module. It depends on if Postgres was configured with OpenSSL support as it relies on OpenSSL to do DES (while with other more modern algorithms it implements them itself).
PGCrypto Algorithms
If openssl support was included and you specify DES as the algorithm to encrypt and decrypt, the data should be the same as you get from Oracle (although you may need to specify padding options).
As Craig says though, the DES algorithm is weak and one of the reasons it is weak is because the output ciphertext is so small.
I have plaintext P and ciphertext C, is it possible to find K key, by which P was encrypted. AES is used to encrypt.
This is called a known-plaintext attack.
Modern ciphers such as AES are not vulnerable to these attacks.
Depends how you define "Possible". It is generally understood, for the moment, to be an impractical task. That said, storing plaintext values with their encrypted counterparts is never recommended. especially if you do this for many sets of plaintext/ciphertext pairs, you increase the amount of information available to the attacker and weaken the encryption.
Does anyone have pros and cons together for comparing these encryption algorithms ?
Use AES.
In more details:
DES is the old "data encryption standard" from the seventies. Its key size is too short for proper security (56 effective bits; this can be brute-forced, as has been demonstrated more than ten years ago). Also, DES uses 64-bit blocks, which raises some potential issues when encrypting several gigabytes of data with the same key (a gigabyte is not that big nowadays).
3DES is a trick to reuse DES implementations, by cascading three instances of DES (with distinct keys). 3DES is believed to be secure up to at least "2112" security (which is quite a lot, and quite far in the realm of "not breakable with today's technology"). But it is slow, especially in software (DES was designed for efficient hardware implementation, but it sucks in software; and 3DES sucks three times as much).
Blowfish is a block cipher proposed by Bruce Schneier, and deployed in some softwares. Blowfish can use huge keys and is believed secure, except with regards to its block size, which is 64 bits, just like DES and 3DES. Blowfish is efficient in software, at least on some software platforms (it uses key-dependent lookup tables, hence performance depends on how the platform handles memory and caches).
AES is the successor of DES as standard symmetric encryption algorithm for US federal organizations (and as standard for pretty much everybody else, too). AES accepts keys of 128, 192 or 256 bits (128 bits is already very unbreakable), uses 128-bit blocks (so no issue there), and is efficient in both software and hardware. It was selected through an open competition involving hundreds of cryptographers during several years. Basically, you cannot have better than that.
So, when in doubt, use AES.
Note that a block cipher is a box which encrypts "blocks" (128-bit chunks of data with AES). When encrypting a "message" which may be longer than 128 bits, the message must be split into blocks, and the actual way you do the split is called the mode of operation or "chaining". The naive mode (simple split) is called ECB and has issues. Using a block cipher properly is not easy, and it is more important than selecting between, e.g., AES or 3DES.
All of these schemes, except AES and Blowfish, have known vulnerabilities and should not be used.
However, Blowfish has been replaced by Twofish.
The encryption methods described are symmetric key block ciphers.
Data Encryption Standard (DES) is the predecessor, encrypting data in 64-bit blocks using a 56 bit key. Each block is encrypted in isolation, which is a security vulnerability.
Triple DES extends the key length of DES by applying three DES operations on each block: an encryption with key 0, a decryption with key 1 and an encryption with key 2. These keys may be related.
DES and 3DES are usually encountered when interfacing with legacy commercial products and services.
AES is considered the successor and modern standard. http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
I believe the use of Blowfish is discouraged.
It is highly recommended that you do not attempt to implement your own cryptography and instead use a high-level implementation such as GPG for data at rest or SSL/TLS for data in transit. Here is an excellent and sobering video on encryption vulnerabilities http://rdist.root.org/2009/08/06/google-tech-talk-on-common-crypto-flaws/
AES is a symmetric cryptographic algorithm, while RSA is an asymmetric (or public key) cryptographic algorithm. Encryption and decryption is done with a single key in AES, while you use separate keys (public and private keys) in RSA. The strength of a 128-bit AES key is roughly equivalent to 2600-bits RSA key.
Although TripleDESCryptoServiceProvider is a safe and good method but it's too slow. If you want to refer to MSDN you will get that advise you to use AES rather TripleDES. Please check below link:
http://msdn.microsoft.com/en-us/library/system.security.cryptography.tripledescryptoserviceprovider.aspx
you will see this attention in the remark section:
Note
A newer symmetric encryption algorithm, Advanced Encryption
Standard (AES), is available. Consider using the
AesCryptoServiceProvider class instead of the
TripleDESCryptoServiceProvider class. Use
TripleDESCryptoServiceProvider only for compatibility with legacy
applications and data.
Good luck
DES is the old "data encryption standard" from the seventies.
All of these schemes, except AES and Blowfish, have known vulnerabilities and should not be used.
All of them can actually be securely used if wrapped.
Here is an example of AES wrapping.
DES
AES
Developed
1977
2000
Key Length
56 bits
128, 192, or 256 bits
Cipher Type
Symmetric
Symmetric
Block Size
64 bits
128 bits
Security
inadequate
secure
Performance
Fast
Slow
AES is the currently accepted standard algorithm to use (hence the name Advanced Encryption Standard).
The rest are not.