I want to encrypt some specific property of a file like encryption type password decryption key these are custom properties.Can anyone tell How can i encrypt those properties?
The same way you encrypt any other data. Find some way to convert the various data into a buffer stream of formatted data (XML/TLV/etc.) and encrypt the buffer. Data is data.
That being said, if you're looking to transport this data along with the file, don't. That defeats the entire purpose of encryption. It only works if you do not send keys (except maybe public keys), passwords, etc along with the data. Rule #1 of encryption is keep your private keys private.
If there were a magic way to do this securely, we wouldn't need PKI.
Hello everyone now i am able to answer my question,
In Alfresco there is a bean name metadetaEncryptor inject that and use to encrypt and decrypt the data. by default it will use your alfresco keystore for key.
Want more info then comment below..............!!
Related
I have a keystring which allows customer to have additional features.
Obviously I would like the software to check that this string is valid, and not modified.
Is the following idea feasible:
get the key string as encrypted value, and encode it in Base64
(my encrypted string is around 100 characters, for my purpose)
calculate the checksum (MD5) of course using a private salt.
weave the checksum into the encrypted data
In principle :
xxxxCxxxxxxCxxxxxxxxCxxxxxxxxxxCxxxxxxxxxxxxxCxxx
the places to weave into the encrypted data could be determined by first cher of the encrypted, creating up to 16 different patterns.
On checking the code validity I simply "unweave" the checksum, test if it's correct, and thereby know if the data has been modified.
Is my line of thoughts correct ?
The cryptographic feature you're thinking of is called "authentication," and there are many well-established approaches. You should strongly avoid inventing your own, particularly using a long-outdated hash like MD5. When an encryption system is authenticated, it can detect changes to the ciphertext.
Your best approach is to use an authenticated cipher mode, such as AES-GCM. Used correctly, that combines encryption an authentication in a single operation. While decrypting an authenticated scheme, the decryption will fail if the cipher text has been modified.
If you don't have access to AES-GCM, the next option is AES-CBC+HMAC, which uses the more ubiquitous AES-CBC with a random IV, and appends a type of encrypted hash (called an HMAC) to the end of the message to authenticate it. In order to authenticate, you need to remove the HMAC, use it to validate that the cipher text is unmodified, and then proceed to decrypt normally. This scheme is generally called "encrypt then MAC."
The implementation details will depend on your language and frameworks.
I have an .Net Application and i want to this application which has some features. Depending client's domain and what features he wants i want to provide him a string which he will store it a file and will be accessible from the application.
I will create a second application which will get as parameters the domain and the features and it will produce the string.
Is there any way to encrypt this string with a key and my application (the first one mentioned) to decrypt it?
I have in mind something like private/public key but reversing the logic. I mean, to encrypt the string from my second application wit the private key and the first application to decrypt it with the public key.
The purpose is the customer to not be able to change the string so that to change the available features.
PS i have an idea to use digital signature, but i dont know if i can have the public/private keys stored at xmlstrings. I think i have seen it somewhere (exporting/importing) but i am not sure
Yes, digital signatures are the correct tool to use for this.
Storing the keys is a minor implementation detail. Typically, such keys are natively represented as binary strings, possibly in ASN.1 or a similar encoding. If you need to store the keys in some format that cannot handle arbitrary binary data, you can always e.g. base64-encode them first.
I want to do searching on encrypted data. Which means that there is the need to have the same ciphertext every time I encrypt the same plaintext. I.e. think of a list of encrypted names and I want to find all "Kevin"'s in it. I would now encrypt "Kevin" and search the database for the encrypted text. All hits will be "Kevin"'s — but still only the one who has the password knows.
Now my question: What about security if I use the same salt and IV (to get the effect described above) all the time? Is the encryption still secure? Or is there any other method to do searching on encrypted data?
If you want to do a deterministic encryption then you should use an encryption mode
that has been designed for deterministic encryption (and not modify an encryption mode designed for something else).
One possibility is the SIV encryption mode described in
RFC 5297.
(Of course, deterministic encryption has its drawbacks, but discussing this is not part of this question.)
A few years ago, when first being introduced to ASP.net and the .NET Framework, I built a very simple online file storage system.
This system used Rijndael encryption for storing the files encrypted on the server's hard drive, and an HttpHandler to decrypt and send those files to the client.
Being one of my first project with ASP.net and databases, not understanding much about how the whole thing works (as well as falling to the same trap described by Jeff Atwood on this subject), I decided to store freshly generated keys and IVs together with each file entry in the database.
To make things a bit clearer, encryption was only to protect files from direct access to the server, and keys were not generated by user-entered passwords.
My question is, assuming I don't want to keep one key for all files, how should I store encryption keys for best security? What is considered best practice? (i.e: On a different server, on a plain-text file, encrypted).
Also, what is the initialization vector used for in this type of encryption algorithm? Should it be constant in a system?
Keys should be protected and kept secret, simple as that. The implementation is not. Key Management Systems get sold for large amounts of money by trusted vendors because solving the problem is hard.
You certainly don't want to use the same key for each user, the more a key is used the "easier" it comes to break it, or at least have some information leaks. AES is a block cipher, it splits the data into blocks and feeds the results of the last block encryption into the next block. An initialization vector is the initial feed into the algorithm, because at the starting point there is nothing to start with. Using random IVs with the same key lowers the risk of information leaks - it should be different for every single piece of data encrypted.
How you store the keys depends on how your system is architected. I've just finished a KMS where the keys are kept away from the main system and functions to encrypt and decrypt are exposed via WCF. You send in plain text and get a reference to a key and the ciphered text back - that way the KMS is responsible for all cryptography in the system. This may be overkill in your case. If the user enters a password into your system then you could use that to generate a key pair. This keypair could then be used to encrypt a key store for that user - XML, SQL, whatever, and used to decrypt each key which is used to protect data.
Without knowing more about how your system is configured, or it's purpose it's hard to recommend anything other than "Keys must be protected, keys and IVs must not be reused."
There's a very good article on this one at http://web.archive.org/web/20121017062956/http://www.di-mgt.com.au/cryptoCreditcard.html which covers the both the IV and salting issues and the problems with ECB referred to above.
It still doesn't quite cover "where do I store the key", admittedly, but after reading and digesting it, it won't be a huge leap to a solution hopefully....
As a pretty good soltution, you could store your Key/IV pair in a table:
ID Key IV
skjsh-38798-1298-hjj FHDJK398720== HFkjdf87923==
When you save an encrypted value, save the ID and a random Salt value along with it.
Then, when you need to decrypt the value, lookup the key/iv pair using the id and the salt stored with the data.
You'd want to make sure you have a good security model around the key storage. If you went with SQL server, don't grant SELECT rights to the user that accesses the database from the application. You wouldn't want to give someone access to the whole table.
What if, you simply just generated a key for each user, then encrypted it with a "master key"? Then, make sure to have random ivs and as long as you keep the master key secret, no one should be able to make much use of any amount of keys. Of course, the encryption and decryption functions would have to be server-side, as well as the master key not being exposed at all, not even to the rest of the server. This would be a decent way to go about it, but obviously, there are some issues, namely, if you have stored your master key unsafely, well there goes your security. Of course, you could encrypt the master key, but then your just kicking the can down the road. Maybe, you could have an AES key, encrypted with a RSA key, and the RSA key is then secured by a secret passprase. This would mitigate the problem, as if you have a decent sized RSA key, you should be good, and then you could expose the encryption functions to the client (though still probably shouldn't) and since the key encryption uses a public key, you can have that taken. For added security, you could cycle the RSA key every few months or even weeks if need be. These are just a few ideas, and I know that it isn't bulletproof, but is more secure than just stuffing it in a sql database.
I was reading this:
http://msdn.microsoft.com/en-us/library/tswxhw92(VS.80).aspx
The first sentence says: "Asymmetric private keys should never be stored verbatim or in plain text on the local computer."
What's the problem with this? And how does a key container solve it.
The reason I'm asking is that I want to generate an asymmetric key pair. The application I'm writing will encrypt information it sends back to me with the public key. I was thinking of storing the public/private key pair in our source control system so that it gets backed up. Shouldn't I be doing that? If not, how should I store the private key so that it can be reliably backed up?
Thanks.
-scott
Update: Does 'never' in the quoted sentence really mean never. Or does it mean I shouldn't be storing keys to source control unless I'm not prepared to take the risk that a hacker could potentially retrieve the keys from our source control system or from a backup taken from it.
Yes, the "never" in the quoted sentence really does mean never.
If the key is stored in plaintext, then anyone with access to that file can read or duplicate your key, then use it to impersonate you. If you display that file on-screen for whatever reason (looking up the key, open the wrong file, editing other information in the file, etc.), then anyone walking past can see it, potentially memorize it, and use it to impersonate you.
A private crypto key is a non-shared secret. If you don't keep it non-shared and secret, it can't do its job properly.
A common solution is to encrypt private keys in the keychain e.g. by using some password-based encryption scheme.
The private key is needed in order to decrypt bits encrypted with the public key, and vice versa. Since the public key is public by definition, you want to keep its private counterpart secret.
Especially when public key crypto is used for digital signatures, it's important to keep the private key secret. Being able to produce digital signatures that can be verified with your public key essentially proves that whoever made the signature had access to your private key.
If you can guarantee that no one but you, or software you trust, can access files on your computer, you don't need to encrypt your private keys. But these are tough assumptions to make.
Because a malicious user can read your key, if he/she gets a hold of your files. Not sure, what the key container does, but I would guess that it encrypts the keys before writing them to a file.