Re: Newbie - Is this Reasonable?


"Larry Lindstrom" <nobody@xxxxxxxxxxx> wrote in message
news:RaCdndFXJI6mdyDZnZ2dnUVZ_s-dnZ2d@xxxxxxxxxxxxxx
John E. Hadstate wrote:
"Larry Lindstrom" <nobody@xxxxxxxxxxx> wrote in message
news:F56dnfgYB6HdsSDZnZ2dnUVZ_sKdnZ2d@xxxxxxxxxxxxxx
Hi Again Folks:

I'm using LibTomCrypt to build my crypto system.

The alphabet soup is AES256, CTR, SHA256 and Fortuna.


Seems like a plausible list.

Keep in mind in what follows that I agree with Paul Rubin:
use EAX mode if possible. The rest of what follows is based
on the assumption that you'll want to look at what's
necessary if you don't.


If you have an aversion to public IVs, consider using
PKCS5v2 to generate your IVs and Keys.

Do I stipulate a
PKCS5v2 output length of the AES key size + the IV size
and send 32 bytes to the key and the other 16 bytes to be
the IV?

Exactly, and add another 16 bytes for the HMAC key.


I use PKCS5v2 to generate the hash of each user's login
password, because this hash is stored in the database. I
was using SHA256 rather than PKCS5v2 to generate the key
from the hash phrase. I think I'll use PKCS5v2 now.


So you use PKCS5v2 to generate a key hash from a salt and
the user's passphrase, then store the salt and the hash in a
database. Do you subsequently use the hash in place of the
user's key or are you just using it to verify that the user
has typed the correct passphrase? Tell me its the latter,
please!


Don't forget to HMAC the salt and the ciphertext and
include the HMAC somewhere in the record.

Thanks Joe and John:

As I mentioned in my response to John's reply, this is
a DB app, not a communication app. Is this a place for
MACs? This involves another key to control.


HMACS: they're not just for comms anymore! Generally, MACs
are even more critical in database applications because the
payoff from tampering with selected fields may be much
higher, fields tend to be fixed-length so it's easier to
tamper with them in a meaningful way, and databases lend
themselves to off-line analysis, so the attacker can
marshall more resources and take more time to attack your
system. You're using a stream cipher for encryption. This
means that meaningful tampering with individual bytes is
much easier and needs to be detected.

Just like the IV and the cipher key, you generate the HMAC
key when you need it from the salt and the user's
passphrase.

Introducing a MAC does require you to deal with the
situation that arises when you detect tampering. That can
be an interesting proposition in its own right.


You should generate the IV from the user-supplied
passphrase the same way you generate the cipher key: use
PKCS5v2 (or use my method of generating all the keys and
IV at one time).

I thought the IV was supposed to be random generated.

Think about that for a second. If the salt is random, and
the user's passphrase is unknown, won't the generated IV be
at least as random as the salt (if you use a
cryptographically credible function to combine them)?


I'm under the impression that leading random text is
important. Trailing random text to obscure the size of
the string. So an attacker wouldn't have a clue that a
person's first name was, for example, 3 letters long.


Leading random text is important for what? Unless the
*amount* of random text is random, I don't see how it brings
anything to the table in this application. If the amount of
random text is random, you may have difficulty recovering
the plaintext. If you don't, then the attacker won't
either. That's adding complexity without much benefit. The
more you do that, the more likely you are to open a hole in
your security.

If you encrypt "Joe<NUL><NUL><NUL><NUL>" with a credible
stream cipher, the attacker still won't have a clue that
Joe's name is three letters long.



.

Relevant Pages

  • Re: Importance of salt
    ... That is the problem with using one-way hash ... The salt is used on ... The attacker really couldn't use his ... > even knows the correct iteration count used. ...
    (microsoft.public.dotnet.security)
  • Re: Hashed password secure?
    ... ]> The stupidly written BSD md5 based unix password function simply runs the ... ]> hash 1000 times to try to slow it down. ... ]impossible for some attacker to create a dictionary of hashes ... As machines get faster, the salt will get more bits, so it ...
    (sci.crypt)
  • Re: password salting
    ... For attacker, I assume pre-computed hash tables are just not that helpful ... You can only add so many iterations to ... |> If you have the salt and the hash, the salt does not make attacking ...
    (microsoft.public.dotnet.security)
  • Re: Hashed password secure?
    ... > Consider the way that a typical password hash attack program works. ... > the salt, and then it hashes the dictionary once for each unique salt value ... So the attacker has to hash the dictionary 2^16 ... want to not store his dictionaries, he'd have to try on average half his ...
    (sci.crypt)
  • Re: Is this secure
    ... What I do in my business layer I get the salt, then I use my custom classes ... to hash the passed in password then send the Hash to a Stored Proc to ... Both the hashed password and salt are stored in the database. ... but then i'd need the salt to create a saltedhash to ...
    (microsoft.public.dotnet.framework.aspnet)