I would like to know whether there are any alternative libraries like JASYPT , which can help me in Encryption / Decryption of passwords.
Yes, there are some. I'm not sure what exactly are you looking for, but I have been using BouncyCastle with great success. Maybe it will interest you as well.
Check out the java security API. It includes a large set of security algorithms and mechanisms for various purposes.
http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136007.html
While looking for implementing crypt functionality, I came across keyczar https://github.com/google/keyczar.
It offers pretty simple api to invoke crypt functions as
Crypter crypter = new Crypter("/path/to/your/keys");
String ciphertext = crypter.encrypt("Secret message");
It also provides api for java/python/cpp languages, and was originally developed by Google security team.
Related
Till now I have used "PBKDF2WithHmacSHA1" for encrypting passwords. However, I recently thought that it would be better to upgrade to "PBKDF2WithHmacSHA512" since it is considered a stronger algorithm.
However, Java does not support "PBKDF2WithHmacSHA512" out of the box. I tried Googling but could come up with no definite solution.
Could you please tell me how can I encrypt passwords using "PBKDF2WithHmacSHA512" in Java. It would be really helpful if you could provide code since I have limited idea about this.
I have an XML file which I want to store on the users machine. I want this file to be encrypted, so that the user won't use/understand the data. When required, this encrypted file will get decrypted and the front-end will read it and use the data. For front-end and Encryption/Decryption I will be using Java.
I need some suggestion on how to do this. Greenhorn in cryptography.
What can be the best approach?
Encryption is very, very easy to do wrong. Wrong in case of encryption means that making a single mistake can break your whole encryption scheme.
When thinking about employing encryption, it's almost always (except in cases of professional security developers) a good idea to use the solutions the provider of your framework did for you. Java offers the cryptography extensions which you can start with here. There are some good examples for using it here.
You could use a base64 encoder/decoder if you want just to prevent viewing or/and editing your XML files directly.
It's not the best possible solution concerning security, but it would work if you want something easy and quick.
I am working on a system which is going to be applied in the real environment. I need to make high security mechanism for the system, one of them is encryption for user's passwords in my database.
I prefer to use one way encryption method to two way encryption, the problem is I want to choose a good algorithm which has good performance and have reasonable reasons to convince my partners why i choose one algorithm instead of other.
Can you give me some tips for doing that?
Don't just use a simple one-way hash.
Use something like PBKDF2 or bcrypt instead. I'm sure there will be good, free, off-the-shelf implementations available for Java (assuming that they're not already included in the JRE itself).
i don't know what kind of argument you're looking for but :
SHA is a good one-way hash functions.
http://en.wikipedia.org/wiki/Secure_Hash_Algorithm
Edit :
I'm using Bcrypt but maybe you should look at Scrypt (http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html)
I'm trying to write an applet that would sign e-mail with S/MIME.
Obviously I want to make one small jar with only the required stuff.
Obviously the Java way of doing that involves having a huge sacred signed Bouncy Castle JCE jar around.
The question is: What's the easiest way of getting S/MIME without touching JCE and having it complain about "authenticating" "providers"? Maybe there is a S/MIME implementation that doesn't depend on JCE? Maybe it is possible to use Bouncy Castle S/MIME using their lightweight API without touching JCE? Maybe there is any other way?
It is obvious to me that nothing can prevent a pure-java open source crypto algorithms from working regardless of whether Sun approves, so it's not a question of theoretical possibility, rather: which way is the least painful?
Of course, I can always go ugly early by grabbing Bouncy Castle pure-java JCE implementation, renaming its packages to java.security1, and making any changes I want - but this way looks too painful right now.
UPDATE My current problem with using Bouncy Castle directly: I try to load keys from keystore, which involves using SecretKeyFactory, which in turn rejects my Bouncy Castle build.
BC S/MIME is written over the CMS package, so the question really devolves to modifying the CMS package so all the crypto is done using the light-weight classes.
Something similar has been done already, more-or-less successfully, for the .NET version of Bouncy Castle. We're trying (admittedly it's a slow process) to refactor the Java version so the CMS stuff can work with either JCE or lightweight. The same issue affects other parts of the BC API too e.g. the PKCS#12 keystore is built into the JCE provider, the OpenPGP package is written to JCE, etc. The .NET ports of these rewrote them to the light-weight API also.
Your problem is probably simpler than the general case though. Presumably you only need the CMSSignedDataGenerator and supporting classes. You probably don't need all the myriad variations of addSigner or generate. If you just decide on your digest/signature algorithms up front, then all the provider stuff will be easy to replace with hardcoded calls to specific lightweight implementations.
Instead of a keystore, maybe you could get away with just storing a single private key in a PKCS#8 file (PEM encoded perhaps). Similarly for the certificate.
It's pretty straightforward to sign messages without using JCE.
The real problem was reading PKCS#12 keys.
I did this:
* Copied JDKPKCS12KeyStore class over.
* Everywhere in it, replaced Security.getInstance() with bcProvider.getService().newInstance() (which returns Spi-s)
* In those Spi-s (in BC sources) made required methods public instead of protected.
It looks like a hack, but seems to actually work.
I need to programatically encrypt a directory of files, like in a .zip or whatever. Preferably password protected obviously.
How can I accomplish this, and WHAT IS the BEST encryption way to do it, if applicable?
Programming language doesn't matter. I am dictioned in all syntax.
How can I accomplish this, and WHAT IS
the BEST encryption way to do it, if
applicable?
tar and gzip the directory.
Generate a random bit stream of equal size to the file
Run bitwise XOR on the streams
Only truly secure method is a truly random one time pad.
I still say 7-zip is the answer. It hasn't been "cracked".
The OpenSSL library has a variety of block cipher implementations including the well-known AES. It has both a function-call interface (for use with languages like C/C++) and a program-call interface (for use in shell scripts). http://www.openssl.org/
4096-Bit (Open)PGP: 'Pretty Good' Privacy !
GnuPG is the GNU project's complete and free implementation of the OpenPGP standard as defined by RFC4880 . GnuPG allows to encrypt and sign your data and communication, features a versatile key managment system as well as access modules for all kind of public key directories. GnuPG, also known as GPG, is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries are available. Version 2 of GnuPG also provides support for S/MIME.
libgcrypt:
http://www.gnupg.org/related_software/libraries.en.html
Edit:
BouncyCastle now has OpenPGP support.
http://www.bouncycastle.org/
Use AES. You'll find implementations in your favourite programming language by asking google for AES encryption + myfavouritelanguage.
If you're using .NET, why not use a free compression framework (http://www.icsharpcode.net/OpenSource/SharpZipLib/) that supports Encryption?