Does the MSAL ConfidentialClientApplication accept ECDSA certificates?
References:
BSI
These are minimal sizes. https://www.keylength.com/en/8/
ECRYPT-CSA
Public Key Primitive: For near term use, 256-bit elliptic curves, and for long term use 512-bit elliptic curves. https://www.keylength.com/en/3/
NIST
These are the minimal sizes for security. https://www.keylength.com/en/4/
I uploaded an ECDSA-SHA384 pub key to Azure.
Invoked acquire_token_for_client()
Received:
TypeError: sign() takes 3 positional arguments but 4 were given
Related
The reason why I ask this question is that we all know that this algorithm will fill the plaintext data into a multiple of 32 bytes,
so how will the key with less than 32 bytes or more be handled?
Because aes256 encryption algorithm is used in many websites or programs,
and usually we don't set a 32 byte password.
In that case, how should the algorithm go on?
Or is there any place where I can perfectly read the algorithms of all modes of aes256?
I am willing to check the source code of the algorithm by myself.
(this is not an advertisement)
but before that, I wrote an encryption algorithm myself.
I named it "sn_aes2048", Its function is:
"if the plaintext data is not a multiple of 256 bytes,
it will be filled with a multiple of 256 bytes, and the key is the same operation.
16 rounds of encryption will be performed by default,
and the data of the key will be updated in each round of encryption.
You may not believe that this algorithm is both symmetric encryption and asymmetric encryption.
Yes, yes, it is an encryption algorithm similar to aes256."
The reason why I ask this question is that we all know that this algorithm will fill the plaintext data into a multiple of 32 bytes,
AES is a block cipher, which must be used with a mode of operation to be used as a general cipher. Some mode of operations (ECB, CBC) require padding (or ciphertext stealing) to be able to operate. So AES - the block cipher algorithm - doesn't do that, and many more modes of operation (CTR, GCM) don't require padding at all.
so how will the key with less than 32 bytes or more be handled?
AES - the block cipher - supports key sizes of 128, 192 and 256 bits, and that's it. It doesn't perform any actions on the key itself.
and usually we don't set a 32 byte password.
Yes but a password is not a key. Both are secrets, but there are different requirements for keys and passwords. You can indeed use a password based key derivation function (PBKDF) as has been commented below. Other methods exist as well such as PAKE schemes.
You may not believe that this algorithm is both symmetric encryption and asymmetric encryption.
I don't believe it can be any good if you don't even understand the concepts of a symmetric key and a password - or the concept of padding which you're trying to re-invent, but feel free to publish a paper.
Or is there any place where I can perfectly read the algorithms of all modes of aes256?
Try "block cipher mode of operation" and "Padding" on Wikipedia for a start. Then buy a book or follow a course on Cryptography. It is an academic field - creating your own algorithm from scratch is like screwing together your own automobile.
Is one of the following two functions preferred over the other?
Do they both do the same thing, just with a different implementation?
crypto/ecdsa/#GenerateKey
crypto/elliptic/#GenerateKey
Both seem to return the same values, just in a different package.
I want to create a private/public key-pair for the following curve
brainpoolP512r1
Thanks in advance! :)
In elliptic curve cryptography the private key is simply a large random number in some range, usually 0 - 2^256, the range is defined by curve itself though, usually the order of some cyclic subgroup, or the entire curve order when dealing with prime order curves.
ECC is used for many things, Elliptic Curve Diffie Hellman, Elliptic Curve Signature (ECDSA) they all require scalar multiplication of a given private key by the curve's generator point to establish the public key.
These scalar multiplication functions are implemented differently for various security and efficiency reasons.
In short are three types of multiplication function:
Fixed-base
Variable-base
Double-base
ECDSA uses fixed-base, ECDH uses variable-base.
There is intuition here, during ECDH you must multiply your private key by someone else's "variable" public point.
Anyway, to use Brainpool, you must generate a key suitable for that curves order, and multiply it by the curves generator point. Usually most API's allow specification of the curve.
By the way, don't use Brainpool, it sucks.
It seems like the Go ecosystem just has a basic bcrypt implementation (golang.org/x/crypto/bcrypt) and it's left as an exercise for the developer to extract the key from the encoded output string to then further expand it to satisfy a particular key length if you're going to be using it as an encryption key rather than just storing it as a password in a DB somewhere. It confounds me that there don't seem to be any quick treatments of this concept online for Go or just in general.
At the risk of introducing a bug by doing it myself, I suspect that I'm gonna be forced to use scrypt, where, at least in Go, it does take an output-length parameter.
Am I missing something? Is there an implementation of bcrypt somewhere in Go that takes a key-length parameter and manages producing a key of acceptable length directly?
Bcrypt is not a key derivation algorithm; it is a password hashing algorithm.
PBKDF2 can take a password and output n desired bits
scrypt can take a password and output n desired bits
These are key-derivation functions. They take a password and generate n bits that you can then use as an encryption key.
BCrypt cannot do that. BCrypt is not a key-derivation function. It is a password hashing function. It always outputs the same amount of bits.
Bonus: bcrypt always outputs exactly 24-bytes (192 bits), because the output from bcrypt is the result of encrypting OrpheanBeholderScryDoubt.
Note: It's not the result of hashing OrpheanBeholderScryDoubt - the bcrypt algorithm is actually encrypting OrpheanBeholderScryDoubt using the blowfish cipher (and repeating the encryption 64 times).
The strenght of bcrypt comes from the "expensive key setup".
Bonus: The strength of bcrypt comes from the fact that it is expensive. And "expensive" means memory. The more memory an algorithm requires, the stronger it is against bruteforce attacks.
SHA-2: can operate in 128 bytes of RAM
bcrypt: constantly touches 4 KB of RAM
scrypt: constantly touches 16 MB of RAM (in the default configuration in Android and LiteCoin)
Argon2: is usually recommended you configure it to touch 1 GB of RAM
Defending against bruteforce attacks means to defend against parallelization. An algorithm that requires 128 bytes can have 7 million parallel operations on a 1 GB video card.
Scrypt, requiring 16 MB of RAM, can only have 62 running in parallel.
Argon2, using 1 GB of RAM, can only have 1 running on a video card. And it runs faster on a CPU anyway.
Kludge bcrypt into a Key Derivation Function (KDF)
You could kludge bcrypt into being a key-derivation function. You can use the standard function PBKDF2 to do it for you.
Normally PBKDF2 is called as:
String password = "hunter2";
String salt = "sea salt 69 nice";
Byte[] key = PBKDF2(password, salt, 32, 10000); //32-bytes is 256 bits
But instead you can use the bcrypt string result as your salt:
String password = "hunter2";
String salt = bcrypt.HashPassword(password, 12);
Byte[] key = PBKDF2(password, salt, 32, 1); //32-bytes is 256-bits
And now you've generated a 256-bit key "using bcrypt". It's a neat hack.
In fact the hack is so neat, that it is literally what scrypt does:
String password = "hunter2";
String salt = ScryptExpensiveKeyHash(password, userSalt, ...);
Byte[] key = PBKDF2(password, salt, 32, 1); //32-bytes is 256-bits
Conclusion
Bcrypt is not a key derivation function. That is the goal of functions like PBKDF2, scrypt (which uses PBKDF2), and argon2.
Using bcrytp when you're only allowed NIST approved algorithms
There is another good reason to use this pbkdf2 construction with bcrypt.
Sometimes a "security expert", who has no idea what they're talking about, will insist that you use PBDKF2 for key derivation. (Yes, it does happen). And you'll try to tell them over and over that PBDKF2 is horribly weak system for key derivation (SHA2 that it is based on runs way too fast, and 10,000 or 100,000 iterations is nowhere near enough to protect you from brute-force attacks - that's what bcrypt, scrypt, and argon2 were invented for).
But this person won't let it go, and will demand the use of PBKDF2. With this construction you can still use bcrypt for security, and PBKDF2 for ignoramus who demands it be in there.
You just happen to use a strong "salt".
I have already developed java card applet.it use RSA for the encryption.So i want to know is there way to speed up the RSA encryption/decryption in java card.the reason is when i used RSA 2048 it takes some extra time than the RSA 512 or 1024.
Thanks
SSV
RSA is inherently slow, and gets slower when you use bigger key lengths. There are however things you can do to speed up RSA operations:
Use a public key with a public exponent that has few bits set to 1, e.g. the fourth number of Fermat, 65537. Note that there are some attacks that can be performed on a public exponent with value 3. This only speeds up public key operations.
use a RSAPrivateCrtKey that includes parameters that can be used for calculations using the Chinese Remainder Theorem. This only speeds up private key operations.
If you have already generated a key pair on the card, chances are that both options have already been lifted by the chip. In that case the solution space may be empty. The only thing you can do then is to switch to Elliptic Curve cryptography (but even that may be slower for public key operations) or a different protocol using symmetric algorithms.
I am looking for a fast encryption/decryption algorithm to be used against spam.
I don't know enough about this field to try and make my own, and in any case, I understand that it would be a bad idea to use something new, so I need some suggestions.
I have looked around SO and tried google but most of the results were explaining how encryption/decryption is slow in order to be hard to break, which I understand, but there are cases when the data expires rapidly and the secret key(salt?) can change very fast, so a fast algorithm would be very useful.
Look at this article on block ciphers. Here is how you can make your own cipher:
Encryption:
Store your own private data, preferably randomly generated for each cipher.
Using your private data as a seed in a pseudorandom number generator. Produce a string of bits as long as the data you want to encode, a.k.a. the plaintext. This string of "random" bits is the key.
For each bit of the key, take the corresponding bit from the plaintext, which we will call a and b respectively. The XOR of the two yields the corresponding bit in the ciphertext.
Use the ciphertext as you wish.
Decryption:
Take the ciphertext and retrieve the private data for it.
Use the private data as a seed in the same pseudorandom number generator to produce the key from before.
Follow the steps above to get the plaintext instead of the ciphertext.
Example:
// ENCODE
plaintext (in bits) = 00100001111110
key (from pseudo-random number generator) = 10101110110101
ciphertext (XOR each bit) = 10001111001011
// DECODE
ciphertext = 10001111001011
key (from pseudo-random number generator) = 10101110110101
plaintext = 00100001111110