I am using visual studio 2005 and C++.
Hello, I use a very good function to sign CryptSignMessage. With this I can specify signed attributes, signatory's certificate, unsigned attributes, if is detached and so on.
However, one of the parameters of this function is the "original document", which according to the documentation this creates a hash of the specified content and signs the hash
I wonder if I can create a signature equivalent, using only the hash of the document. I do not have the document, I have only the hash.
I found CryptSignHash, but this function does not allow specify parameters as signed attributes or unsigned attributes and/or signatory's certificate. According to my research, this function seems to return a PKCS#1, where later I should set up a structure of signature PKCS#7. So would be grateful to know if there is any way to make a signature with the hash and if there is a way to create a PKCS#7 structure from PKCS#1 using windows functions. Or Is there any way to sign only the hash, which is as simple as using CryptSignMessage?
#update 1
The CryptSignHash does not return PKCS#1. Return a byte array with PKCS#1 padding.
I tried to use CryptMsgOpenToEncode and CryptSignMessage passing the contents as "NULL" and adding the hash to signed attributes, they calculate the hash of empty.
Is there any way to do this using Windows functions?
Its a bad idea to sign a hash without calculating the hash yourself. See Sign a Hash, Generate digest and signature separately, and MFSA 2006-60.
Related
I'm using flatbuffers, in its' schema, some field can set as hash. Eg:
table Person {
age: int (hash:"fnv1_32" );
}
what is this for ?
I'm using
flatc --cpp --gen-object-api Person_KeyHashTest.fbs
How to set 'rehash' and 'resolver' in the generate function ?
Could someone give me an easy example ?
See hash in https://google.github.io/flatbuffers/flatbuffers_guide_writing_schema.html
It allows you to turn strings into integers in the binary representation.
The resolver function allows you to specify a way to lookup such a hash to an object you have created elsewhere. This allows you to do things like having objects in one buffer refer to ones in another. The actual implementation of these functions is up to you, it can be whatever you want.
consider (for an example) that we have encrypted a file (sample.txt) using win-zip 9 by typing a password "agoodpassword".
now if we try to open the file by typing some wrong password, we get a error message saying: the password typed is incorrect.
the question:
how can a software verify if the password typed in is correct or not? the content of the file could be any random data, so checking for errors in the file after decryption is not going to work. But still the software needs some source to verify this password; so how does this win-zip software verify if the decryption is successful or not?
What I suspect is the password could also be there in the same file being encrypted. Is it true or does the software adopt any other method?
Instead of just encrypting, many applications that create a ciphertext also create an authentication tag. This authentication tag can be checked before decryption; if the authentication tag is incorrect than one of the parameters (key, IV or ciphertext) is incorrect.
To use encryption using a password it is common to utilize PKCS#5 (password based encryption). PKCS#5 contains a password hashing method that utilizes "key stretching", making it harder for an attacker to test/compare many passwords using brute force or dictionary attacks. Such a password hashing method is called a Password Based Key Derivation Function or PBKDF. The latest PKCS#5 describes PBKDF2.
Now if you want to create a new password based encryption method, I would propose to do the following:
Perform a PBKDF2 with (very) high iteration count and 128 bit salt;
Make sure that the user gets feedback about the strength of the password;
Perform a KBKDF (key based key derivation function) on the result of PBKDF2, creating a check value, a data encryption key, and a data authentication key;
Use the data encryption key for an encryption method, say AES-128-CBC with random IV;
Use the data authentication key for a HMAC over the IV and the ciphertext;
Store the check value;
To verify the correct password during decryption, use the check value.
Note that I did not discuss the KBKDF yet. You may use a hash over the output of the PBKDF2 and a simple counter or string for that, say SHA-256(key seed, "ENC").
You can use a hash value to provide a very high probability that anything other than the correct password will be rejected. Basically, if you hash a password it produces a number with a certain number of binary digits, and a good cryptographic hash will produce a completely different number (in as much as random thing tend to differ) if you type something even the tiniest bit different (for example, changing the order of two characters, or using uppercase instead of lower).
There's still a very small chance that two different passwords will produce the same hash value... for example if you only had a 32-bit hash value then there's about a 1 in 2^32 (4 billion) chance. It gets quite mathematically complex to create a hash function that doesn't let you retrieve the password (especially if it is a short password, and someone can pre-generate a list of short words with specific hash values too), so you probably want to have a pretty weak hash - just good enough to avoid returning corrupt data for 99.99% of typos - and/or one that's known to be resistant to such attacks.
What kind of technique does use Google Plus to generate users' unique ids?
Example
https://plus.google.com/102766325060234825733/posts
You can only assume that they are randomly generated ID's that are large enough to be generated non-sequentially with sufficient entropy.
The ID's are too big to be stored in a bigint field which is interesting, again probably due to the required entropy and non-sequential requirement (so that nothing can be inferred by comparing userid's).
A simple encryption of a serially generated number, with a secret key can be used to generate the IDs. It can be a 1 way hash, or a decryptable encryption.
The reason for not using serial numbers directly is obvious: You can easily guess userids of other users on the network, which can result in Bots scraping the content of the network.
I'm writing a database front end for a website. Next to the records I want to include a link likes this:
Record 1 - [Add][1] [Edit][2] [Delete][3]
But I want to protect these links from being used more than once. My thinking is to pass a hash value then store a list of valid HASH values in a table somewhere and only process requests with valid hash values. Is there a better way to do is?
Update: The answer to this question led me to ask this question: What is the difference between a "nonce" and a "GUID"?. Why exactly would you use a nonce instead of a GUID?
Your idea is correct, except that you should use cryptographically secure random bytes (a "nonce") instead of a hash.
We have a situation in our product where for a long time some data has been stored in the application's database as SQL string (choice of MS SQL server or sybase SQL anywhere) which was encrypted via the Windows API function CryptEncrypt. (direct and de-cryptable)
The problem is that CryptEncrypt can produce NULL's in the output, meaning that when it's stored in the database, the string manipulations will at some point truncate the CipherText.
Ideally we'd like to use an algo that will produce CipherText that doesn't contain NULLs as that will cause the least amount of change to the existing databases (changing a column from string to binary and code to deal with binary instead of strings) and just decrypt existing data and re-encrypt with the new algorithm at database upgrade time.
The algorithm doesn't need to be the most secure, as the database is already in a reasonably secure environment (not an open network / the inter-webs) but does need to be better than ROT13 (which I can almost decrypt in my head now!)
edit: btw, any particular reason for changing ciphertext to cyphertext? ciphertext seems more widely used...
Any semi-decent algorithm will end up with a strong chance of generating a NULL value somewhere in the resulting ciphertext.
Why not do something like base-64 encode your resulting binary blob before persisting to the DB? (sample implementation in C++).
Storing a hash is a good idea. However, please definitely read Jeff's You're Probably Storing Passwords Incorrectly.
That's an interesting route OJ.
We're looking at the feasability of a non-reversable method (still making sure we don't explicitly retrieve the data to decrypt) e.g. just store a Hash to compare on a submission
It seems that the developer handling this is going to wrap the existing encryption with yEnc to preserve the table integrity as the data needs to be retrievable, and this save all that messy mucking about with infinite-improbab.... uhhh changing column types on entrenched installations.
Cheers Guys