After much reading of the latest Bind9 AMD, did I correctly sense the diminishing usage over the year of Public/Private SIG(0) in favor of shared-key TSIG for AXFR/IXFR transactions?
Why is shared key the preferred mean of authentication? And why only limit to nsupdate/dynamic-DNS tools?
What is wrong with Public/Private Key approach and it’s ability to encrypt the zone transfers?
It does seems a bit more attractive to be using ED25519 over HMAC-SHA512 for protecting a DNS zone transfer.
Related
I did all the encryption process setting a secureKey but I chose Blowfish algorithm, but now I need to use AES as the algorithm but I changed the config in the secure property config (in my global) it seems that is not recognizing the algorithm change, and if I want to encrypt I still need to choose Blowfish and the same secureKey, to desencrypy or encrypt
Do you know why?
or what can I do to modify the algorithm?
If you encrypt information with an encryption algorithm you must use the same algorithm to decrypt it. You can not use a different algorithm. That's how encryption work.
Encrypt again the properties with AES this time and then use also AES in the secure properties configuration.
I have been creating a few certificates using OpenSSL recently and in the process of creating the certificates, the program asks me questions such as my location, details about my business and the like.
My question is whether knowledge of these details can aide an attacker in breaking my encryption and if so, is spoofing the data the optimal solution?
How can I securely store the p12 file?
As per my knowledge the in p12 file certs are encrypted with RC 40 bits and keys are encrypted with des3 but brute force is the technique which can reveal the password of certs and then same can be used to get the keys and this makes the p12 file bit insecure.
I want my p12 file to be securely stored in the file system.
Can I encrypt this file and store it.If yes, then will the file still be usable.
PKCS#12 by definition does not define what algorithms are legal to use. PKCS#12 is just a structure of a container for certificates and private keys. That container can be encrypted and signed. See more here: https://www.rfc-editor.org/rfc/rfc7292
Theoretically any encryption could be brute forced. The question is what is the cost and effort to do that successfully. By picking up a trusted algorithms (see the list of NIST approved algorithms for example) you can sleep your night rather well knowing that your private key inside of an encrypted PKCS#12 container would remain safe against brute force.
If your PKCS#12 file uses 3DES encryption it could still be considered safe. See more here: https://security.stackexchange.com/questions/146710/is-the-3des-algorithm-secure
But if you want to restrict access to the PKCS#12 file and the private key inside of it, cheap option would be restricting permissions of the file in the file system. This basically means that only the user running the process have access to that file. More pricier options would be to use hardware tokens and HSMs. Some vendors are SafeNet and Thales for example and you can use those through crypto engines and interfaces such as PKCS#11. The PKCS#12 file could also be protected by a passphrase, which is often recommended if you can tolerate human interactions. In server environments or other use cases where human interaction is not possible, passphrase protected PKCS#12 may be tricky since you need to find a way to protect the passphrase itself.
I wanted to know what is the best way to encrypt storage at rest. Lets say financial information for 1000 users is on a system. Besides making sure nobody unauthorized gets to how do we encrypt the data that is being used everyday so that if god forbid they get it, it should be impossible for them to decode or read?
I believe AES is a correct measure?? How can i implement AES using PHP for phpmyadmin data?
Neither SHA nor MD5 are encryption algorithms, so forget them for now.
The answer to your question is more organizational then technical. First you need to identify what storage you plan to use for the data. If it is the DBMS, then (a) it can offer certain encryption and authentication mechanisms, and (b) you can store the files of the DB on the encrypted storage.
If you have files (either the data itself or the DB with the data), you can store them on encrypted disk. This can be an encrypted NTFS disk or virtual encrypted disk (the one which resides in a file and is mounted as a virtual disk by software).
If you create backups of the data, then backup tools usually offer encryption mechanisms too.
In all of the above cases used algorithms don't matter too much: modern algorithms, offered by above mentioned mechanisms, are secure enough given that you choose 128-bit or larger key for symmetric encryption and choose long passphrase (more than 22 characters if you only use [A-z0-9] alphabet for 128-bit symmetric encryption).
There exists symmetric encryption and public-key encryption (PKI encryption). PKI lets you encrypt the files using public keys (private key is used for decryption), and one of the benefits is that you can encrypt the data for several different private keys. This means that any of the given set of keys can be used for decryption, and the owner of one key doesn't need another key for decryption. The benefit is that you can assign keys to certain users or roles instead of sharing a single passhprase.
The above is just a small guideline and you need to learn a lot (or better involve a security specialist) before you implement the solution, cause security made wrong is worse then no security at all (cause it gives false sense of protection and this makes people careless).
That depends on your platform; most modern operating systems offer disk encryption options with various degrees of security. Note that SHA and MD5 are hash algorithms and thus unsuitable for encryption.
I'd base my choice of algorithm on the capabilities of the system that is supposed to work with the data. Some CPUs have special instructions for AES processing, which gives a significant speed boost here; also, there are harddisk controllers that include encryption support.
Dedicated hardware has two major advantages: it is significantly faster, and it is more difficult to retrieve the symmetric key as a prelude to stealing the actual disk drives.
Has anyone got practical experience or a reference for a scheme that implements a key management scheme that would comply with the PCI DSS security standard?
There are obviously quite a few implementations around given the number of companies compliant with PCI DSS but trying to find details of them is tough. When it gets down to storing private data the discussion normally stops at which encryption algorithm to use. After that there's normally a statement about appropriately storing the private key but no discussion about practical ways to do it or things like periodically changing the key or providing the key to applications etc.
Specificlly I'm interested in thee requirements from sections 3.5 and 3.6 of the PCI DSS standard.
3.5.2 Store cryptographic keys securely in the fewest possible locations and forms.
3.6.a Verify the existence of key-management procedures for keys used for encryption of cardholder data. Note: Numerous industry standards for key management are available from various resources including NIST, which can be found at http://csrc.nist.gov.
3.6.4 Verify that key-management procedures are implemented to require periodic key changes at least annually.
I've had a look at the NIST Cryptographic publications as the PCI DSS requirements document suggests but apart from recent notes of a Cryptographic Key Management Workshop there doesn't appear to be much there in the way of real implementable schemes or standards.
As to what I'm trying to do it's not:
Store passwords + salts as one way hashes for authentication,
Choose a strong symmteric algorithm for data encryption,
Avoid needing to store private data in the first place.
Avoid the need for key management with other mechanisms: physical security, database security, dragons and wizards etc.
All of which are valid concerns but in this case are not the answer. The nuts and bolts of my requirements are in a different SO question .Net Design pattern for storing and retrieving sensitive per user data but it all boils down to key management hence this more refined question.
I'm familiar with the pain you're going through. We struggled to update an old EFT system towards PCI compliance. Key management was certainly (from my software point of view) the most challenging part.
I think I also stumbled into the NIST Recommendations for Key Management that Martin posted, and got incredibly frustrated with the lack of concrete examples.
ANSI X9.17 - Financial Institution Key Management is probably the most relevant to your needs, with PCI-DSS. Good luck reading it though, the document is a massive collection of TLA's which I know I certainly struggled to read. (X9.17 is updated yearly, and latest version is now: NIST SP 800-57 Pt. 1 Rev. 4 )
When frustration turned to desperation I stumbled into The Electronic Money Mill which is a fictional tale, with a good number of relevant technical references. Chapter 17 discusses X9.17 and may help with the understanding.
From all this reference material I designed a key management system that our auditor was pleased with. The design documents are fairly lengthy, but in summary the idea is that you have your Data Encrypying Key protected by a Key Encrypting Key, and the Key Encrypting Key is stored on a physically separate box, itself protected by a Master Key.
My implementation was to have a Key Server application running on a windows box. This application required entry of two separate 'key server master keys' before it could be used. These keys would be known only to the key server administrators. These keys are xor'd together to generate the Master Key, which is stored only in protected memory whilst the application is running. Application can then automatically generate cryptographically strong Key Encrypting Keys, which are stored in encrypted form using the Master Key.
Applications that have a need for encryption will request a Key Encrypting Key from the Key Server. The KEK is used by the application to encrypt/decrypt the Data Encrypting Key, which can be stored securely with the application data.
Good luck. I hope you also find it an interesting challenge!
Have you seen NIST SP 800-57, Recommendation for Key Management?