I am working on a remote backup project in C...
I want to send data and compress as well as encrypt the data.
However I am confused whether to compress first or encrypt first!
What will be better?:
Compress the data and then encrypt it
Encrypt the data and then compress it
Also I am going to use zlib for compression.
And I am wondering which encryption lib to use...
Some people say libgcrypt is good.
Suggestion for good encryption libraries(very easy to use) will be appreciated... :)
or is there anything that does both of the jobs?
Thanks!
You should compress before encrypting.
Any good encryption algorithm will produce random-like data that will not compress well.
My favorite easy to write, understand and use algorithm is blowfish. There are a few implementations at that link in a few liens of code.
It's roughly the same level of security as something like AES/DES, ie pretty much unbreakable. As with all crypto the real vulnerability is going to be you and your users!
Related
I am writing a site that needs to use multiple encryptions through out the entire process. I started to use CryptoJS v3.1.2 vSHA3 (512) and am able to encrypt the data no problem. Where I'm having trouble is decrypting the data once it's been encrypted. I have been searching the web for the last week or 2 and have only been able to find ways to encrypt the data but no way to decrypt it. If there is no way to decrypt the data, I will have to look for a different encryption. Any help here would be gratefully appreciated.
SHA3 is a hash function, and hash functions are not reversible -- that is, not decryptable. You may instead need a symmetric algorithm such as AES.
That being said, getting the nuances of cryptography right to avoid vulnerabilities is notoriously hard even for veterans, much less someone new to these concepts. Try very, very, VERY hard to rely on standard and ready-made solutions. Use things like HTTPS, for example, or your database's built-in security features.
I have a Java application (an ESB - Enterprise Service Bus) which deals with customer sensitive data and have a requirement of supporting Data encryption at rest in order to prevent data abuse.
The application stores customer data for processing on the file system and application interacts with it through java.io.File API. So basically, I need to encrypt the file before it is persisted on the file system by the application and then decrypt it before application reads it so that it can be parsed and processed.
Are there any good frameworks or libraries that can help me implement Data encryption at rest? I am planning to use PGP encryption/decryption for implementing Data encryption at rest.
I am looking for best and recommended approach for implementing Data encryption at rest within my Java application and any help shall be appreciated.
Why on Earth would you think pgp is the right tool for this? Seems to me that you only need a symmetric key solution, so pgp feels like the wrong answer.
Cryptography in Java is a minefield. Easy to do things wrong, hard to do things right.
Having said that, you have a better chance to not screwing up if you use BouncyCastle rather than something else. They have example code that shows you how to do various operations.
For encrypting data at rest, I recommend you use AES in either CBC mode or CTR mode. If using CBC mode, make sure you choose your IV in a cryptographic secure way (unpredictable). Also, never re-use an IV for any mode of operation.
You should also consider whether you need message integrity. General guidance about symmetric encryption here.
Even though people often get crypto wrong, the bigger problem is key management. That's a whole new can of worms (and don't be fooled into thinking pgp provides a solution to this: all it does is shifts the problem to somewhere else).
I am currently using Solr to perform search services over some sensitive records.
As Solr/lucene provides fast searching by storing inverted indexes of the sensitive information in plain text on a disk there is a requirement to encrypt these index files so that unauthorized people can't have access to them by bypassing the system's security.
I found there are similar patches open on Apache JIRA AES encrypted directory and Codec for index-level encryption.
AES encrypted directory looks promising but this patch has been implemented for lucene 3.1 as I am using the newer version, I am not sure if this patch can be used with lucene version 5 or higher.
I was wondering if there is a way to implement a security measure that encrypts the indexes or if it is possible to write some custom plugin which can encrypt/decrypt the indexes on I/O level(i.e FsDirectory)?
The discussion in the comment section of LUCENE-6966 you have shared is really interesting. I would reason with this quote of Robert Muir that there is nothing baked into Solr and probably will never be.
More importantly, with file-level encryption, data would reside in an unencrypted form in memory which is not acceptable to our security team and, therefore, a non-starter for us.
This speaks volumes. You should fire your security team! You are wasting your time worrying about this: if you are using lucene, your data will be in memory, in plaintext, in ways you cannot control, and there is nothing you can do about that!
Trying to guarantee anything better than "at rest" is serious business, sounds like your team is over their head.
So you should consider to encrypt the storage Solr is using on OS level. This should be transparent for Solr. But if someone comes into your system, he should not be able to copy the Solr data.
This is also the conclusion the article Encrypting Solr/Lucene indexes from Erick Erickson of Lucidwors draws in the end
The short form is that this is one of those ideas that doesn't stand up to scrutiny. If you're concerned about security at this level, it's probably best to consider other options, from securing your communications channels to using an encrypting file system to physically divorcing your system from public networks. Of course, you should never, ever, let your working Solr installation be accessible directly from the outside world, just consider the following: http://server:port/solr/update?stream.body=<delete><query>*:*</query></delete>!
I use OpenCL in my program, and i need to protect opencl code from reading by other users. Compile code to binary maybe the option, but if exist some way to decompile it, this option is useless. I cant allow to somebody steal my opencl code. How i can do opencl protection? Thanks!
It really depends on how determined an attacker you need to guard against. Generally any sufficiently determined attacker can reverse engineer your code if they have access to the compiled code, but it may not be worth the effort.
It might be a performance hit, but you could do things like have the binary image use some self-extracting encryption at runtime, like communicating with a licence server and only decrypting the rest of the code if a licence is valid. That can suffer from man-in-the-middle or replay attacks, etc (especially if the underlying hardware can be virtualized), unless you specifically guard against that too. Presumably you don't have cooperation of the hardware in keeping your code secure, but do you need to consider runtime vulnerability, or just in storage?
Chances are compilation is sufficient protection against casual IP theft; obfuscation is a slightly higher bar, then options get progressively more expensive to implement.
Use a dynamic compilation method that authorizes using facebook account that has the original opencl string so youd known who stole it at least. Maybe even using an encryption of your own to mix the string into a meaningless clobbered char array.
You can never protect against decompilation.
Today, you can compile and ship binaries, but the format is different for each platform, and perhaps even devices within that platform, so you'd be shipping a lot of binaries.
In the future, you can use SPIR. It's nascent today but will be your solution in the future.
If your app already has some protection (ofuscation, etc..) then as long as the OpenCL code is a static string inside your app it will be protected. However, clever attacker may be able to get it out as well.
The best way is to precompile and distribute the kernel binaries, but that will be tedious task, and it may be reversed by an attacker as well.
I'm trying to develop my own encryption algorithm for J2ME mobile application with MIDP2.0.
But I don't have any experience in encryption algorithm, Guys please give ideas for me.
I would like to encrypt document and I need to maintain that document in resource directory, Thats why I need encryption from hacking others.
Don't. Crypto is highly specialised, and the smallest mistake can result in a weak cypher. There are plenty of good crypto algorithms out there, such as AES, Salsa20 and others. Use one of them. That also saves you the trouble of writing your own code since there are libraries available.
Read Bruce Schneier on amateur cryptography: Memo to the Amateur Cipher Designer and when you have read it, drop any thoughts of designing your own cypher and use one of the standard cyphers. AES-CTR + HMAC or AES-GCM are my personal preferences, YMMV.
a) I completely agree with rossum. Don't write your own encryption. It's really bad idea (one wrong step and it won't be secure at all).
b) I believe there is Bouncy castle encryption library (http://www.bouncycastle.org/latest_releases.html) which supports J2ME.
c) I recommend to read following article which gives information and examples for encryption/decryption of data on j2me (http://www.ibm.com/developerworks/java/tutorials/wi-encrypt/index.html)