This may sound like a strange question, and it feels a bit bizarre that I actually have to ask this, but after spending a couple hours looking over the MSDN documentation for the bcrypt routines that were added in Vista, I've almost reached the conclusion that there is no actual bcrypt support!
According to Wikipedia:
bcrypt is an adaptive cryptographic hash function for passwords
... based on the Blowfish cipher ... Besides incorporating a
salt to protect against rainbow table attacks, bcrypt is an adaptive
hash: over time it can be made slower and slower so it remains
resistant to specific brute-force search attacks against the hash and
the salt.
However, from the documentation on MSDN, the "bcrypt" library is apparently actually a generic interface for encryption and hashing. You have to obtain a handle to an "algorithm provider" via the BCryptOpenAlgorithmProvider function, which has several built-in algorithms to choose from. But the word "blowfish" does not appear anywhere in the list.
So am I missing something? Am I reading this wrong? Or does Windows's "bcrypt" library not actually support bcrypt at all?
In the context of the MSDN, BCrypt is a shortform of "BestCrypt", but the PR name for it is:
Cryptography API: Next Generation (Cng)
It is implemented in bcrypt.dll.
BestCrypt/BCrypt/Cng is the successor to the older CryptoAPI.
Microsoft is slowly removing references to "BestCrypt" from their site, but you can still see it in some pages like:
SHA256Cng Class
This algorithm is for hashing only and does not provide any encryption or decryption. It uses the BCrypt (BestCrypt) layer CNG.
It's interesting (to me anyway) that the .NET framework generally can provide you three implementations for the each kind of crypto algorithm. For example, for SHA2 hashing, there is:
SHA256Managed: an implementation written purely in managed code
SHA256CryptoServiceProvider: a wrapper around the native Cryptographic Service Provider (CSP) implementation
SHA256Cng: a wrapper around Cryptography Next Gen (Cng) implementation
Short version
No, bcrypt is short for bestcrypt. And, no, it doesn't support bcrypt (blowfish crypt) password hashing.
the BCrypt APIs are generic and support various cryptographic hash algorithms, but bcrypt is not one of them. The B Prefix seems to be just a way to distinguish between the older APIs and the Next Generation.
Related
Is it possible with the CNG (Windows Cryptography API: Next Generation) to generate BCrypt / SCrypt / Argon2 hash password ?
BCrypt is a computationally difficult algorithm designed to store
passwords by way of a one-way hashing function. You input your
password to the algorithm and after significant (relative)
computation, an output is produced. Bcrypt has been around since the
late 90s and has handled significant scrutiny by the information
security/cryptography community. It has proven reliable and secure
over time.
Scrypt is an update to the same model from which Bcrypt arose. Scrypt
is designed so as to rely on high memory requirements as opposed to
high requirements on computational power. The realization that lead to
this, was that specialized computer chips (FPGA/ASICs/GPUs) could be
purchased at scale by an attacker easier than could huge amounts of
memory for a traditional computer.
Short Answer
No.
Long Answer
Neither CryptoAPI nor Crypto API Next Generation (CryptNG) support bcrypt, scrypt, or argon2
bcrypt is a customized version of the blowfish encryption algorithm. Blowfish is not supported by CNG. And even if it was, bcrypt uses a version of bcrypt with a custom "expensive" key setup.
scrypt is (nearly) PBKDF2, which is supported by CNG:
Byte[] scrypt(String password, int DesiredNumberOfBytes, ...)
{
Byte[] salt = SpecialScryptSaltGeneration(password, ...)
return PBKDF2(password, salt, DesiredNumberOfBytes, 1);
}
but the SpecialScryptSaltGenration uses primitives not included in CNG (ChaCha, Salsa/20).
Argon2 uses custom primitives that don't exist anywhere.
I want to know if there is a successor for X9.31 (AES) based generators in crypto++ library, since the X9.31 cannot be used after December 2015 (NIST SP800-131A)?
If you're looking for an approved CSPRNG, then you want either the HMAC DRBG or the Hash DRBG, both of which are approved by NIST and are in Crypto++. You will want to seed it using the OS CSPRNG, which is also available in Crypto++.
The HMAC DRBG has been found to be slightly more likely to resist attacks, but the Hash DRBG is going to be faster in a typical implementation. There are no known practical attacks on either when used correctly.
If you don't have a strong need for compliance, I'd go with just using the OS PRNG and stick with that. The OS PRNG is going to be robust and secure and even if you picked another algorithm, you'd still need to seed with it anyway.
If you do need to pick an approved algorithm for compliance reasons but don't otherwise have a strong preference, use an HMAC DRBG with SHA-512, seeded from the OS RNG, which provides the best possible security and the best possible performance for an HMAC DRBG on 64-bit systems.
I am trying to encrypt using Rijndael 256-bit block size, 256-bit key size, ECB mode and zero's for padding.
I was trying to use OpenSSL::Cipher::AES.new(256, :ECB) but I cannot for the life of me get the correct result I am looking for.
I have a solution in C# but I'm having trouble getting the Ruby equivalent for it.
In the C# code RijndaelManaged is used for encryption and what I'm having trouble with in particular is RijndaelManaged is ok taking in a byte array for the key and the object to be encrypted. I can't find a Ruby library that will do the same for me. OpenSSL::Cipher::AES will only take in strings.
Is there anything similar like this in Ruby? Google has failed me in finding anything and I'm not an encryption guru by any means. Any help or just point me in the right direction would be amazing. I just cannot figure out for the life of me. I have a related SO question to this if anyone wants to take a look. The answer is perfect I just cannot translate it to Ruby.
This question isn't a duplicate. I mean it is similar to the question it is listed as a duplicate of however the answer doesn't help me at all. The answer they link to is a library that uses :cbc but I need :ecb mode for the Rijndael encryption. I agree though the questions are very similar. Just the answer doesn't help me hence me asking this question.
I think the only gem in existence that could accomplish this task for me turned out to be the ruby-mcrypt gem. For any future generations who are in need of a library to encrypt some lesser used and potentially unsafe encryption technique.
I need some mechanizm of safe storing passwords in database with inverse algorithm(that's why hashing unfortunately does not fit).
Does anyone know about such algorythms and how to realize one of them in PostgreSQL?
May be any secret-key cryptography?
Although I would strongly advice you to be very cautious about what you are trying to accomplish here; yes a secret-key cryptography would be a good solution to your problem.
Fortunately, PostgreSQL provides support for encryption and it can be achieved as easily as this:
Select encrypt (info_to_encrypted, key, algorithm_name);
The topic might be lengthy and thus I'd direct you to check these excellent slides:
Encrypted PostgreSQL
Also please read this very good stackexchange question before you proceed with what you're trying to do.
I think there is no way of storing a password safely with an invertible algorithm, because it is the idea of these algorithms is that everything they encrypt can be decrypted and therefore they will always be unsafe.
I am implementing a custo crypto library using the Diffie-Hellman protocol (yes, i know about rsa/ssl/and the likes - i am using it specific purposes) and so far it turned out better than i original expected - using GMP, it's very fast.
My question is, besides the obvious key exchange part, if this protocol can be used for digital signatures as well.
I have looked at quite a few resources online, but so far my search has been fruitless.
Is this at all possible?
Any (serious) ideas are welcome.
Update:
Thanks for the comments. And for the more curious people:
my DH implementation is meant - among other things - to distribute encrypted "resources" to client-side applications. both are, for the most part, my own code.
every client has a DH key pair, and i use it along with my server's public key to generate the shared keys. in turn, i use them for HMACs and symmetric encryption.
DH keys are built anywhere from 128 up to 512 bits, using safe primes as modulus.
I realize how "pure" D-H alone can't be used for signatures, i was hoping for something close to it (or as simple).
It would appear this is feasible: http://www.quadibloc.com/crypto/pk050302.htm.
I would question why you are doing this though. The first rule of implementing crypto is don't implement crypto. There are plenty of libraries that already exist, you would probably be better off leveraging these, crypto code is notoriously hard to get right even if you understand the science behind it.
DSA is the standard way to make digital signatures based on the discrete logarithm problem.
And to answer a potential future question, Ephemeral-static Diffie-Hellman is the standard way to implement asymmetric encryption (to send messages where you know and trust the recipients public key (for example through a certificate), but the recipient does not know your key).