Re: Newbie - Is this Reasonable?

John E. Hadstate wrote:
"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!

Thanks John:

This is they way this currently works. I'm prepared to
change any part of this process.

User name and password are used to gain access to the
application. The user name can be revoked and the password
can be changed by the user. The row in the user table has
a field that is a hash of the password.

Once the user has logged in, they enter a pass phrase
which is currently hashed to generate the key for any
database queries for that session. Storage for the
password is the user's head.

Mike Amling suggested a pass phrase escrow table with
all of the pass phrases encrypted with a public key. I
like the idea, but I think work on that can wait until
current issues are resolved.

A hash of the key is kept with each record, and if
this doesn't match the key for the session "Encrypted"
will be displayed in the encrypted fields, instead of
ciphertext. An alternative is a password verification
field, which will be tested to see if it decrypts to
the original text, probably a field of zeros.

Only some of the fields of the database are encrypted,
those fields that are needed for the SQL WHERE clauses
are in clear text, and include such things as gender and
age.

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.

Ok, I'm convinced.

Selected rows in different tables are encrypted. So I
guess I need a nonce for each encrypted field.

Can a nonce be a 32 or 64 bit value? Or do they need
to be longer? Each field in the database will need to
include a nonce, not a storage problem, but I need to keep
track of the last nonce I use. Do I just keep a table in
the database with the next nonce to be used?

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 not a mathematician, when I think about any of this
my head starts to hurt. :)

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.

I read this group's Google archives, I remember someone
saying random data should proceed the cyphertext so an
attacker who happens to know what "Yes" encrypts to can't
look for it in matching ciphertext. And another post
admonished against trailing NULLs. What cypher, what mode?
I don't remember.

I appreciate your advice.

Thanks
Larry
.

Relevant Pages

  • Re: protecting .NET assemblies against hackers
    ... encryption keys, connection strings or any other sensitive ... You must always assume that an attacker has full access ... underlying CLI code. ... >passwords used to access remote data, like a database server). ...
    (microsoft.public.dotnet.security)
  • Re: Decrypt fails
    ... MD5 and MD2 are hashing algorithms and cannot be used to encrypt/decrypt. ... Actually, since hashing algorithms can be regarded as 'one-way' encryption, ... Create an MD5-hash of the password and store ... that he provided and compare it to the hash in the database. ...
    (microsoft.public.platformsdk.security)
  • Re: embedded keys - there has to be a less vulnerable approach
    ... the database would be run on top of an encrypting file system ... > The use of an asymmetrical encryption algorithm does not seem to offer ... because the encryption and decryption ... > a hostile attacker is not a member of that small knowledgeable elite. ...
    (comp.security.misc)
  • Re: Decrypt fails
    ... I am creating a MD5 hash data and then using it to derive a key ... (CALG_RC2 encryption algorithm). ... My requirement concerns more with not storing passwords in plain ... > that he provided and compare it to the hash in the database. ...
    (microsoft.public.platformsdk.security)
  • Newbie request for help checking his secure file format
    ... FXSSLDevice uses a proprietary file format for its secure files. ... An attacker can not know from the file format: ... A hash of the symmetric key, but this is never the same for the same ... performed by EORing in random data prior to encryption and up to eight ...
    (sci.crypt)