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.
Related
Which is the standard size of the MAC generated with SHA-2?
it is safe if I trunk the message and then send it to destination ?
Thank you in advance for your consideration
First of all, do not use only the SHA2 hash funcion, but use HMAC (with SHA2).
Now for answering your question: In theory, you can use any size for your MAC, depending on your security requirements. However, the most recommended standard tag size is 128 bits (16 bytes).
We got this error when running this command :
[cacti ~]$ snmpwalk -v 3 -a MD5 -u super -x AES -X AAAAAA 10.X.X.X
2011-01-20 16:58:12 Error: passphrase chosen is below the length requirements of the USM (min=8).
2011-01-20 16:58:12 snmpwalk: (The supplied password length is too short.)
Error generating a key (Ku) from the supplied privacy pass phrase.
Do you have any idea how to decrease the USM's length parameter? We can't change the password that is under 8 characters..
You are fighting the IETF RFC if you insist using a short passphrase,
https://www.rfc-editor.org/rfc/rfc3414
If the Appendix A algorithm is used, SNMP implementations (and SNMP
configuration applications) must ensure that passwords are at least 8
characters in length.
This is a standard, so your only choice is to use a long enough passphrase.
For AES, the recommended passphrase length is 12,
http://www.ietf.org/rfc/rfc3826.txt
The following are recommended in regard to user passwords:
Password length SHOULD be at least 12 octets.
Password sharing SHOULD be prohibited so that passwords are not
shared among multiple SNMP users.
Implementations SHOULD support the use of randomly generated
passwords as a stronger form of security.
I am using AES block cipher in CBC mode to encrypt by data. I am confused of using the appropriate error correcting code that can used with CBC block cipher for data retrievability? Can anyone help me?
You should use AES CMAC (different from AES MAC) to provide integrity protection and authentication of the message. To do this, you should use a different key. The AES-CMAC should be calculated over the encrypted message.
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.
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.