Is it possible to set up AWS KMS in a way so that it would generate same ciphertext for the same text (e.g. alpha) each time?
And if not, what others cryptographic methods should I use? (it would be great if they have libs for node.js as well)
Related
I am searching for a way to encrypt a file via AES using Swift in my Cocoa Applications.
As far as I can see the common frameworks (i.e. CryptoSwift) are supposed to encrypt text only.
Is there a specific framework for this job or is there any kind of macOS built in method for this?
Thanks!
Yes, using CommonCrypto is a good start. I would not recommend using any homegrown implementations however.
Doing security right is hard, AES is no exception to this.
You need to use a proper key of the correct length ( 64 or 32 bytes preferred )
You need to use padding ( I recommend PKCS7 ) in case your data is shorter than the blocksize / keysize. AES is not secure on its own and this bit is important.
You also really want to use an initializationVector, ( either appendend or prepended to the final data stream ) since otherwise it would be possible for an attacker to draw correlations between several encrypted streams from the same key
You should also make use of a HMAC ( SHA2-256 and up, also available in commoncrypto ) in order to prevent tampering with your encrypted data and giving you unexpected and potentially harmful result data.
The list goes on, but my memory fails me at this point since It has been a while since I needed to create an implementation.
I would highly recommend googling around for a standard implementation that wraps around CommonCrypto.
I would also suggest that using anything that is written as is ( I.E. CryptoSwift ) is not recommended as the codebase isn't proven and went through proper vetting like Apple's frameworks are.
I'm following some python book and the author provides an example of using crypt to produce a hashed password. Using the salt+password; and later he mentioned that the same could be done for sha512 using hashlib library. So I tried to use
hashlib.sha512(password+salt).hexdigest()
to see if I could come up with my same password in the /etc/shadow file, but I'm not getting anything remotely similar. I'm using the salt that shows as part of my password hash. Am I doing it correctly, or that salt needs to be in ascii form? Also does the salt goes first and then the password like hashlib.sha512(salt+password).hexdigest()? the rest of my code is pretty simple. It is that part about finding the salt, and hashing it properly. nagios:$6$P9zn0KwR$tgfvvFWJJ5FKmoXiP5rXWOjwoEBOEoAuBi3EphRbJqqjWYvhEM2wa67L9XgQ7W591FxUNklkDIQsk4kij uhE50:16632:0:99999:7:::
for example the salt I'm using is "P9zn0KwR" is this correct or I need to find the clear text for that salt... thanks
Using hash algorithms like MD5 or SHA-* is an unsecure way to store passwords, because they are ways too fast and therefore can be brute-forced too easily.
Have a look at the Phyton docs, the part about key stretching. It seems that they implemented the PBKDF2 for passwords which is recommended. The passlib seems to be a good choice too, they support the BCrypt algorithm.
I am designing a protocol to exchange IOUs (digital promissory notes).
These should be digitally signed, but the signature should be independent from the data representation (whether its XML, JSON, binary, little or big endian numbers).
Is there any standard on how to sign a list of strings and primitive types (like integers, floating points, booleans)?
There isn't one standard encoding, but you can specify canonical forms for particular encodings.
For json you could specify that there is no whitespace outside strings and that keys should be sorted in a particular way.
For ASN.1 there is DER encoding, which is the canonical form of BER.
There is Cryptographic Message Syntax (CMS), but I don't know much about it.
The better question is what is the best format for verifying digitally signed Data primitives.
The answer is xml formatted and signed according to the XAdES standard. XAdES is harmonized with the related standards and many implementations participate in interoperability tests hosted by etsi.
Unless it is easy to verify a digitally signed format, the signature has limited value.
You can sign any bit stream and store/maintain the signature as a detached signature. But then you and the relying parties (the recipients) need to deal with two files. One for the data and one for the signature.
The advantage of xml with XAdES is that the format enables the signed xml file to include the digital signature.
You can create an equivalent of XAdES for another data format such as json. But a new format has limited use unless it becomes popular and standardized. XAdES has already accomplished this, so it is the way to go.
Added
Re: comment--
I want to provide non-repudiation. I understand that I have to save the information I signed. But I was hoping that I don't have to save it as XML but could rather save all values included in the signature in a database (less verbosely) and uniquely reconstruct the signed string from them before verifying.
Technically, you can do that. You'll need to watch out for spacing issues within the xml. But practically, not a good idea. Why:
Proving non-repudiation requires that you meet the applicable burden of proof that the alleged signer really did sign the data.
You may be trying to convince the original signer of this, an expert third party (an auditor) or non-experts (lawyers and juries). You want to make it easy and simple to convince these people. Schemes such as "re-creating" the signed file are not simple to understand compared with "here is the original signed file. Its signature verifies and it was signed with the digital certificate belonging to Susan Signer."
To keep it simple, I'd suggest signing an XAdES XML file. Then extract the data from the file and use it in your dbms. Hang on to the original signed file in your dbms or elsewhere. In case of a dispute, produce the original file and show that it verifies. A second part of the audit would be to show that your dbms has the same data values as the signed XML.
The programming and storage costs of hanging on to the original, signed, xml file are de minimis, when compared with your goal of proving non-repudiation of the data.
By the way, how is the signer's certificate managed? If it is anything less than a QSCD (Qualified Signature Creation Device), such as storing the cert in the file system, then you have another problem: no way to conclusively prove that the certificate wasn't used by an imposter. Use a secure system for signing such as CoSign (my company) or an equivalent system.
Is it 'safe' to store cipher parameters in the (unencrypted) header of an encrypted file? Is there anything (other than the key of course!) that shouldn't be stored/transmitted in the clear?
You are using a symmetric encryption, where storing the blocksize, blockmode and keysize would be safe, since you don't (mustn't) make keys available as you stated.
But all such params are in general useful to attackers. If the file cannot easily be associated with a cipher and used params (or the software respectively), an attacker would have considerably more work to do and that's what encryption basically is for. A cipher is secure, while (and because) everyone can see how it works. Additionally trying to hide some information can also add some security.
AES has a fixed block size of 128bits, which itself is not a critical information, knowing of AES itself already. So this one is not needed inside the file header.
The keysize is given by the key itself, so it can be left out too.
The blockmode is the remaining parameter. Just never use ECB. Permanently use a single blockmode like OCB and you don't need to store it in the file aswell.
Predefining all params at both sides is a solution, if you don't intend to change them per file.
Error checking can be done using checksums, which are also critical information, so you may encrypt them together with the data or provide them together with the key.
Perhaps, following approaches can help if you have to transmit the params anyway:
Transmit params in the key file, if you're up to define the format yourself and the keys were distributed on a per file basis.
You could also define different settings by mapping them to some randomly defined enumerators, which don't provide valuable information without knowing the software.
Now I want to encrypt or decrypt some data in object-c use DES algorithm ,can somebody give me some suggestion?
First point. AES has replaced DES as the de-facto encrpytion standard, at least for the banking industry.
Second Point: Irrespective of what algo you decide on, this is what you have to do.
Add the Security.framework to your project.
Import the "CommonCrypto/CommonCryptor.h" file. This contains all the interfaces for symmetric encryption.
Using the methods in this class, you can define your encryption algo (AES, DES, etc.), the key size, padding that you want to use, etc.
You have to option of a one-shot API for encryption/decryption (CCCrypt()) or more advanced options if needed.
Hope this helps. Let me know if you need any particular information.
A code sample can be found in How to encrypt an NSString in Objective C with DES in ECB-Mode?
As the referring topic describes, you will have to keep in mind that DES uses a 56-bit (7 bytes) key and 64-bit (8 bytes) blocks.
Although DES is symmetric you will have to decrypt data by providing the kCCDecrypt option to the CCCrypt function.