Can anyone explain why the CryptImportKey function accepts an hPubKey of 0 (the decryption key handle), when importing an encrypted session-type key-blob from another computer?
The environment is this:
PC #1: Generates a key exchange key-pair (public/private) in a local key-container (CryptGenKey w/ AT_KEYEXCHANGE), then exports the public portion as a PUBLICKEYBLOB and sends it to PC #2
PC #2: Takes the public key-blob from PC #1 and imports it to a local key-container. Creates a session key in the same local key-container. Exports the local key-container session key to a SIMPLEBLOB (CryptExportKey), using the public key that was imported from the client's key blob (this is used to encrypt the session key).
PC #1: Takes the encrypted session key-blob from PC #2 and calls CryptImportKey, providing the local key container hProv, the key-blob buffer pointer and length, 0 (zero) for hPubKey and flags, and a pointer to an HCRYPTKEY handle.
After doing the above I get a valid handle back, and can call CryptEncrypt and CryptDecrypt using the handle I got back. Yes, if I specify on CryptImportKey the handle of the key exchange key-pair generated from the first step above on PC #1, that works as well. I just don't understand why a 0 for hPubKey works, it's as if the CryptoAPI "knows" what the private key was to encrypt the data.
Thanks.
The only thing I can think of is that you use this within a session (which has context, thus knows the private key), or that you are not actually encrypting the data. Note that it is actually possible to look up the private key using the modulus as a unique key, but I could not fathom that they would use such a method without telling the user.
PS sorry, I cannot make comments to your question directly (yet), so I posted this because of the long time frame.
Related
I'm trying to understand the key exchange happening with CurveMQ described here.
http://curvezmq.org/page:read-the-docs
My understanding of public key cryptography is you use a public key to encrypt data that can then be decrypted by the corresponding private key. In the CurveMQ specification it describes encrypting data from a key to a key. See the excerpts below they reference 2 keys. What does this mean in layman's terms?
The signature box (80 octets). This SHALL contain 64 zero octets,
encrypted from the client's transient key C' to the server's permanent
key S.
and
A welcome box (144 octets) that encrypts the server public transient
key S' (32 octets) and the server cookie (96 octets), from the server
permanent key S to the client's transient key C'.
there.
I'm still quite confused when I want to develop ESP32.
I'm planning to create a special (.bin) for the Serial Number, Public Key and Private Key.
I've also read the document from ESP32 but I'm still confused about making an address (Serial Number, Public Key and Private Key). Can anyone tell me, how to make an address on ESP32?
Thank you
Hope you all are doing well.
I am trying to set parameters like passphrase and latency in srt url. But, i need to know whether while setting passphrase parameter, is it necessary to set pbkeylen value also? If yes, then what is purpose of pbkeylen parameter in passphrase? or what is role in that srt url of pbkeylen?
Thank you.
As described in the documentation, pbkeylen defines the key size used for the AES encryption. It is independent of the passphrase.
It is not necessary to set it - it will default to 16 bytes (128 bit), or whatever the other end of the connection sends in the handshake if it has been set there.
the application tries to access the registry key values using advapi.dll regqueryvalueex method which works fine in xp (32-bit) but return 2 on windows 7(64-bit). however regopenkeyex opens the registry keys successfully in both the machines.
tried these below steps already but still couldn't read the registry key values
1. tried running vb 6 ide as admin
2. moved the registry keys to wow64node in regedit
For some reason, you are targeting the advapi.dll library, which was created for 16-bit Windows. I don't know how you are even getting it to work even in Windows XP, since this is a 16-bit only DLL, which will not load into a Win32 process, unless there is some kind of thunking layer.
As for the return value of "2" for RegOpenKeyEx(), the documentation tells you:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724911%28v=vs.85%29.aspx
Return value
If the function succeeds, the return value is ERROR_SUCCESS.
If the function fails, the return value is a system error code.
If the lpData buffer is too small to receive the data, the function
returns ERROR_MORE_DATA.
If the lpValueName registry value does not exist, the function returns
ERROR_FILE_NOT_FOUND.
Googling "System error code" gives you: http://msdn.microsoft.com/en-gb/library/windows/desktop/ms681382%28v=vs.85%29.aspx
The bit you need is:
ERROR_FILE_NOT_FOUND
2 (0x2)
The system cannot find the file specified.
It is very likely that if you were trying to use advapi.dll in your declare statement you would get this error when trying to run the API call. Basically, check your declare statements.
Of course, if you could supply your code, we would know for sure, rather than trying to do psychic debugging.
Microsoft says:
The CryptEncrypt function is not guaranteed to be thread safe and may return incorrect results if invoked simultaneously by multiple callers.
Does this mean that the function modifies global data?
Or does it simply mean that you can't use the same hash/key simultaneously?
(In other words, is the comment below correct?)
It means what it means: the function is not guaranteed to be thread-safe. It probably has an internal static (or global) state, but that's an implementation detail.
Whether you use or not the same hash or key is irrelevant.
Edit after comment: according to this MSDN page, CryptoApi key handles are not thread safe because of the internal key state:
Most algorithms and modes require that data be decrypted in the same order that it was encrypted. This is a difficult task in a multithreaded environment because use of a critical section will not address the ordering issue. If you are using a block cipher (that is, RC2, DES, or 3DES) in ECB cipher mode, then this issue is not a factor because the internal key state does not change. However, ECB is not the default cipher mode. CBC is the default cipher mode. With CBC cipher mode, the internal key state does change.
So after all, it would seem reasonable to think that you can indeed use CryptEncrypt on several threads if they don't share the same key. This is merely a guess, though.
I believe it means that you cannot fork several processes at the same time to use it because the function uses shared address space. It has access to the memory of all the threads and therefore will give you unexpected results. This should only be a problem with multi-threading if your application is doing that.