Ah, I see your confusion, and I should have been more careful to forestall
it.
That's not what is meant here by a dictionary attack. What you describe is
what is defended against by the iteration.
The dictionary attack defended by a salt is where a *pre-computed*
dictionary of keys for likely
Hi,
1st link was to simply show mention of longer bit length SHA
algorithms in Android SDK, not how to go about effectively using them,
which usually involves 'salt' and other measures as other have
discussed here and else where.
MD5 (128 bits) is 'weaker' than SHA1 (160 bits) only by virtue of
Here you go.
This is some old code for a fairly light encryption job. You might want to
adjust the algorithm a bit to use at least SHA (also maybe not use DES).
I think I'd also make the salt mutable based on a second input, but it
really depends on how much you care about protecting what your
Nod to Bob on not doing it yourself... there is no reason to do so.
There is nothing worse than your masterpiece of unbreakable encryption that
only you don't know is full of holes.
I've seen some pretty silly things done in the name of extra encryption
and it's just not worth your time.
--
Arg, just reread your opost.
All you want is a hash (as in a one way hash)?
The encryption decryption confused me ;)
SHA is likely adequate... simply do a google search for java sha and
you'll find a tone of examples on digesting a string... most of them will
work in Android.
- Brill
--
You
Ahh... love this little library.
See:
http://www.jasypt.org/howtoencryptuserpasswords.html
- Brill
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from
No, he thinks he just wants a hash to construct a key from a password.
Probably, he just wants to encrypt / decrypt, in which case, your code is
mostly adequate, except for a serious flaw, of a constant salt. A constant
salt defeats the purpose; you can construct a perfectly fine dictionary of
Salt doesn't prevent dictionary attacks at all. If I know that the
password is an 6-character alpha then I can try all combos of that,
dictionary or otherwise, regardless of how salted the encryption is.
I've seen iteration add considerable overhead. In one SqlCipher
implementation iteration
http://developer.android.com/reference/java/security/spec/MGF1ParameterSpec.html
SHA256, 384, 512
http://developer.android.com/reference/java/security/MessageDigest.html
MD5 is weaker than SHA
On May 10, 3:52 pm, pasamblue1 parulcha...@gmail.com wrote:
I am developing an android application
On Tue, May 10, 2011 at 3:59 PM, gjs garyjamessi...@gmail.com wrote:
http://developer.android.com/reference/java/security/spec/MGF1ParameterSpec.html
SHA256, 384, 512
What does the mask generation function has to do with this?
Don't just paste random links.
How about PBKDF2. This one is as per FIPs standard.
Is SHA1 also a standard from FIPs.
On May 10, 12:52 pm, Nikolay Elenkov nikolay.elen...@gmail.com
wrote:
On Tue, May 10, 2011 at 3:59 PM, gjs garyjamessi...@gmail.com wrote:
For your purposes any standard hash algorithm that produces the
desired number of bits should be fine. The weakness of hash
algorithms has to do mostly with the ability to counterfeit data
that produces a given hash value -- this is an important consideration
when the hash is being used in a
The fundamental problem with starting with a human-managed password is that
there is not a lot of entropy -- the possible values are not distributed
over a huge range, compared to what an attacker could try with
trial-and-error.
So just doing SHA1 or SHA256 for that matter, is not sufficient
https://www.kb.cert.org/vuls/id/836068
https://www.kb.cert.org/vuls/id/836068Nothing new should have been using
MD5 for a looong time, and people need to know to stay away from it.
Fake SSL certs that exploit this have been produced. It's not just a
theoretical concern.
On Tuesday, May 10,
On Wed, May 11, 2011 at 8:32 AM, Bob Kerns r...@acm.org wrote:
https://www.kb.cert.org/vuls/id/836068
Nothing new should have been using MD5 for a looong time, and people need to
know to stay away from it.
Fake SSL certs that exploit this have been produced. It's not just a
theoretical
Of course, hashing a password, per se, doesn't really make it any
stronger. And doing things like using a salt don't do much if the
concern is simple trial-and-error cracking of a single encrypted
message (unless you're relying on security by obscurity). Salting
does help prevent known plaintext
On Wed, May 11, 2011 at 7:34 AM, Bob Kerns r...@acm.org wrote:
More precisely, you iterate this:
hash = f(hash)
where f is some function that is expensive, and does not collapse the space
of possible values into some smaller set. One way to accomplish this would
be:
f(hash) = hash xor
On Wed, May 11, 2011 at 12:35 PM, DanH danhi...@ieee.org wrote:
Of course, hashing a password, per se, doesn't really make it any
stronger. And doing things like using a salt don't do much if the
concern is simple trial-and-error cracking of a single encrypted
message (unless you're relying
I think you missed part of what I was saying. It's important, so let me try
to be more clear.
Each of the two components does a different job.
The salt prevents dictionary attacks, by expanding the space of dictionaries
by the size of the salt (say, 2^128 or whatever you use.)
The protection
No -- I've always been fortunate enough to have Bouncy Castle or similar
packages available, and haven't had to implement it myself. I *have*
implemented similar things in the distant past before we knew quite as much
about the problems and solutions. I.e. with a salt, with an insecure hash
20 matches
Mail list logo
