We Keep Coding

Javascript equivalent to Java SHA1PRNG

I have a Java Application that uses "AES-128 bits/ECB/PKCS5Padding" (java8 linux/window), the code is quite simple
KeyGenerator keygen = KeyGenerator.getInstance("AES");
SecureRandom secureRandom = SecureRandom.getInstance("SHA1PRNG");
secureRandom.setSeed(seed.getBytes());
keygen.init(128, secureRandom);
...
Because I can't find the javascript equivalent to SHA1PRNG algorithm I can't decrypt the text using js code. But after reading Decrypt AES/CBC/PKCS5Padding with CryptoJS and with some trials I found that for an 128 bits seed (32 bits hex-string) using SHA1PRNG in java I can get the same result by SHA1 twice in js
CryptoJS.SHA1(CryptoJS.SHA1(seed)).toString().substring(0, 32) //using 'crypto-js'
The python code here also confirms that! But why ?
def get_sha1prng_key(key):
'''[summary]
encrypt key with SHA1PRNG
same as java AES crypto key generator SHA1PRNG
Arguments:
key {[string]} -- [key]
Returns:
[string] -- [hexstring]
'''
signature = hashlib.sha1(key.encode()).digest()
signature = hashlib.sha1(signature).digest()
return ''.join(['%02x' % i for i in signature]).upper()[:32]
---- update ----
The comments I got suggested my question is a duplicated question. But I checked those 2 questions and I don't think so. But first of all, I knew the java codes misuse a pseudo random number generator and it is seed as a key derivation function, it is bad. But that is actually someone else codes and my job is to use js to decrypt the encrypted text.
Second, I haven't figured out why sha1 a 32bit hex-string twice will get the same result as java 8 SHA1PRNG sun implementation(and hence the question).
I read Use of "SHA1PRNG" in SecureRandom Class
"SHA1PRNG" is the name of a pseudo random number generator (the PRNG
in the name). That means that it uses the SHA1 hash function to
generate a stream of random numbers... There is no clear description of the algorithm available

How to make SJCL and Python hashlib generate identical pdkdf2 output

I have a JavaScript app and a Python app that communicate using a key derived from a password using pbdkf2. The problem is, the generated keys don't match. I've produced a minimal test case for each.
Python
import hashlib, binascii
bytes = hashlib.pbkdf2_hmac('sha256', "password".encode(), b'', 100000)
print(binascii.hexlify(bytes).decode())
Generates: 64a868d4b23af696d3734d0b814d04cdd1ac280128e97653a05f32b49c13a29a
JavaScript
<script src="lib/sjcl.js"></script>
<script>
var hmacSHA256 = function (key) {
var hasher = new sjcl.misc.hmac(key, sjcl.hash.sha256);
this.encrypt = function () {
return hasher.encrypt.apply(hasher, arguments);
};
};
hash = sjcl.misc.pbkdf2("password", [0], 100000, 256, hmacSHA256);
console.log(sjcl.codec.hex.fromBits(hash));
</script>
Generates: 41c04f824d843d5be0ae66b3f621d3f05db7d47e7c46ee0e9171b5cbff7f3631
I'm scratching my head a lot now. I think b'' and [0] are equivalent salts, but I'm not sure. I think they both use utf-8 to encode the password, but I'm not sure. And I'm not convinced the JavaScript hmacSHA256 function exactly matches what Python is doing. Or it could be something else still.

Off the top of my head, have you checked if
hash = sjcl.misc.pbkdf2("password", "", 100000, 256);
gives the correct result?
As far as I can tell from the docs, SJCL's PBKDF2 implementation defaults to HMAC-SHA256 if you don't explicitly give it a PRF. If making that change fixes the bug, then there's probably something wrong with your hmacSHA256 wrapper.
Also, I'm not sure if specifying an empty salt as [0] really works (or is guaranteed to work in future versions, given that the format of SJCL's bitArrays is explicitly subject to change), but "" definitely should work.

This is sharing for the rest based on my recent experience.
My objective:
To generate PBKDF2 password using Python. The client will be Android (Java), and the back end will be on Flask (Python).
Issue:
While testing, I discovered that both versions (Java vs Python) produced different hashing output (all other parameters were equal - SHA256, 1000 iterations, similar SALT)
What I have found out:
Using PBKDF2 generation tools available on the internet, the Android result was an exact match, while the Python was not. So there is a good chance the Python result was somehow skewed .....
Problem solved:
While looking for possible explanation in SO, I discovered that the way I converted String to bytes in Python was somehow not entirely correct:
Original code:
dk = hashlib.pbkdf2_hmac('sha256', b'base64_message', b'salt', 1000)
Working code:
dk = hashlib.pbkdf2_hmac('sha256', base64_message.encode(), salt.encode(), 1000)
This is probably due to my lack of experience in Python. Hope this note will be of use to others, especially those who are new to Python!

How to Format OpenSSL Keys to Match Online Sample (JSBN-ECC)

I want to be able to format the public key of Elliptic Curve Diffie-Hellman in OpenSSL - Ruby into something like this online example (link), as I have been using that JS library.
My code below generates an OpenSSL::PKey::EC public and private keys
#Ruby
ec = OpenSSL::PKey::EC.new('secp128r1')
ec.generate_key
ec.private_key
#--> 205607153615223513963863936713567041725
ec.public_key.to_bn
#--> 499599043529551953518354858381998373780459818901085313561109939106744612770290
Try copying the private key above 205607153615223513963863936713567041725 and pasting it on the online (link) as Alices' Private value. But click the secp1284r1 button first to have same curve parameters, and then click Compute Public button.
That will generate a public key from the inputted private key. However, the Ruby OpenSSL documentation isn't really helpful, and I am stuck on figuring out how to convert the generated public key above:
499599043529551953518354858381998373780459818901085313561109939106744612770290
Into something like this (as seen from the online site):
x: 107060165679262225845922473865530329196
y: 109296969851421346147544217212275741170
I've assumed that by properly converting one, it can somehow become equal to the other since they have same curve parameters. Or am I wrong? (And also because the default format of point_conversion_form is :uncompressed, as I just have tested) Please help.
P.S. You might wonder why I need to convert the public key into the other. No, I don't really have to. I just want to learn how to convert it as I'll be using that method to convert something similar. And this is the simplified question for your testing-convenience.

Jay-Ar,
You shouldn't find your solution weird as I think the call to ec.public_key.to_bn might be adhering to rfc5480 section 2.2 re: Subject Public Keys which states:
2.2. Subject Public Key
The first octet of the OCTET STRING indicates whether the key is
compressed or uncompressed. The uncompressed form is indicated
by 0x04 and the compressed form is indicated by either 0x02 or
0x03 (see 2.3.3 in [SEC1]). The public key MUST be rejected if
any other value is included in the first octet.
Assuming this is the case and since you stated the format is :uncompressed, your own answer makes total sense to me. Thanks for posting it! :)

ec.public_key.to_bn
#--> 499599043529551953518354858381998373780459818901085313561109939106744612770290
It would probably be better to print that in hex.
The public key is a point on the curve. That is, its an (x,y) coordinate. So that value probably needs to be split (hence the reason for printing in hex). Taking a guess:
x = 499599043529551953518354858381998373780
y = 459818901085313561109939106744612770290
The public key is a point because its derived from the base point G, which is also a point. G is sometimes expanded as (g_x, g_y). The private exponent is a (or b), which is a scalar or integer. So the public key is A=G^a or A=(g_x, g_y)^a, which is a point.
And also because the default format of point_conversion_form is :uncompressed, as I just have tested
Point conversion/compression is just a presentation layer optimization trick. It omits the y portion of the coordinate because you can solve for it given x. Because its a curve, sometimes you need to send +1 or -1 to specify the quadrant the y coordinate lies in. But again, its just an optimization and only matters for interop'ing. After you read the point into a library, both x and y are available.
You might wonder why I need to convert the public key into the other...
Nope :)
But one thing you might want to be aware of is OpenSSL's "named curve" flag. If you want to load an EC key into an OpenSSL based server, you will want to ensure the private key and resulting certificate have the OPENSSL_EC_NAMED_CURVE flag. Otherwise, you'll get bizarre errors like "no shared ciphers" when trying to connect to the server. See ECDH and Named Curves on the OpenSSL wiki for details.

Finally! I somehow managed to convert it properly but it's somehow weird.
#From above code
c.public_key.to_bn
#--> 499599043529551953518354858381998373780459818901085313561109939106744612770290
#irb:
require 'openssl'
key_int = '499599043529551953518354858381998373780459818901085313561109939106744612770290'
key_bn = OpenSSL::BN.new(key_int, 10) #Convert to OpenSSL::BN (Big Number, with 10=Decimal as base)
key_hex = key_bn.to_s(16) #Convert to Hex String (16=Hexadecimal)
#--> "04508B09B35FA8C21820BE19C16B38486C5239D4A932D081DD56B90F91120551F2"
#I don't really know why, but removing '04' above will finally convert it properly
key_hex = key_hex[2..-1] #Remove first 2 chars: '04'
#--> "508B09B35FA8C21820BE19C16B38486C5239D4A932D081DD56B90F91120551F2"
#Split key_hex into halves
key_hexarr = key_hex.chars.each_slice( (key_hex.length/2.0).round ).map(&:join)
#--> ["508B09B35FA8C21820BE19C16B38486C", "5239D4A932D081DD56B90F91120551F2"]
#Convert first value into BN (input: 16=hexadecimal), then convert to string(output: 10=decimal)
key_x_int = OpenSSL::BN.new(key_hexarr[0], 16).to_s(10)
#--> "107060165679262225845922473865530329196"
#Convert second value into BN (input: 16=hexadecimal), then convert to string(output: 10=decimal)
key_y_int = OpenSSL::BN.new(key_hexarr[1], 16).to_s(10)
#--> "109296969851421346147544217212275741170"
Finally, key_x_int and key_y_int now matches the result from the online link

Base64 HMAC SHA1 String in VBA

I'm trying to convert an ASP/VBScript OAuth library to VBA. One of the challenges is this line of code:
Get_Signature = b64_hmac_sha1(strSecret, strBaseSignature)
This function, b64_hmac_sha1 is actually a function contained in a JavaScript library. It appears to me that calling a JavaScript function from VBA is fairly impractical.
Because I know so little about encryption, it's not even clear to me what this b64_hmac_sha1 function does. Is HMAC SHA1 different from SHA1?
I half suspect I might be able to find some VBA code online to do what I need to do if I just understood what this function is actually doing. If I do not find an existing function, I could possibly write one that would use the .NET Cryptography library (you can actually call the .NET cryptography libraries from VBA if you know how).
I'm not looking for someone to convert this JavaScript to VBA. I'm only trying to understand what it is that this b64_hmac_sha1 function is outputting so I can try to find ways to achieve the same output in VBA if possible.
A copy of this JavaScript library is visible on this website. You'll have to scroll down past the VBScript to the JavaScript section.
http://solstice.washington.edu/solstice/ASP_Signing_REST_Example
Edit1:
OK, so here's the functions I ended up writing and using:
Public Function Base64_HMACSHA1(ByVal sTextToHash As String, ByVal sSharedSecretKey As String)
Dim asc As Object, enc As Object
Dim TextToHash() As Byte
Dim SharedSecretKey() As Byte
Set asc = CreateObject("System.Text.UTF8Encoding")
Set enc = CreateObject("System.Security.Cryptography.HMACSHA1")
TextToHash = asc.Getbytes_4(sTextToHash)
SharedSecretKey = asc.Getbytes_4(sSharedSecretKey)
enc.Key = SharedSecretKey
Dim bytes() As Byte
bytes = enc.ComputeHash_2((TextToHash))
Base64_HMACSHA1 = EncodeBase64(bytes)
Set asc = Nothing
Set enc = Nothing
End Function
Private Function EncodeBase64(ByRef arrData() As Byte) As String
Dim objXML As MSXML2.DOMDocument
Dim objNode As MSXML2.IXMLDOMElement
Set objXML = New MSXML2.DOMDocument
' byte array to base64
Set objNode = objXML.createElement("b64")
objNode.DataType = "bin.base64"
objNode.nodeTypedValue = arrData
EncodeBase64 = objNode.Text
Set objNode = Nothing
Set objXML = Nothing
End Function
Using this function:
Debug.Print Base64_HMACSHA1("abc", "123")
VAsMU9SSWDe9krP3Gr56nXC2dsQ=

HMAC is a construct for turning a hash function, like SHA1, into a Message Authentication Code (MAC).
Normal hash functions don't have any secret data associated with it. This means that anyone can compute the digest, assuming they have the original input. HMAC uses a secret key, so that only those in possession of the key can compute outputs.
Suppose I have a file, file.txt. I want to send this to you, and we need to make sure nobody tampers with it. Sorry, I have no clever way to represent this with just text.
me -> file.txt -> you
me -> SHA1(file.txt) -> you
Then you verify the result by computing your own SHA1 digest, and verifying it matches what I sent you.
Now suppose an attacker was in the middle. Unfortunately, because there is no secret involved, the attacker can modify the file, and compute his own file/digest pair. When you compute your version, it'll match what he sent you, and you'll be none the wiser.
me -> file.txt -> attacker -> modified.txt -> you
me -> SHA1(file.txt) -> attacker -> SHA1(modified.txt) -> you
With HMAC, we add a secret key to the computation.
me -> file.txt -> you
me -> SHA1_HMAC(file.txt, our_secret) -> you
When you compute your version, you apply the secret key as well, and the result matches. The attacker, without knowledge of the key, can't replace the digest.
me -> file.txt -> attacker -> modified.txt -> you
me -> SHA1(file.txt) -> attacker -> SHA1_HMAC(modified.txt, // DOESN'T KNOW KEY) -> you
HMAC is a very specific way of adding the secret key. Unfortunately, simple methods of just concatenating a key to the end of the file, or pre-pending it before hashing, are vulnerable to different attacks (length extension attacks, for example).
The B64 is Base64 encoding the output, to make it pretty.
What this code is ultimately doing is taking some input, and some secret key, and computing a 160-bit digest, and base64 encoding the result.
There is an implementation of SHA1 HMAC in .NET
This looks like an implementation of Base64 for VBA
I hope this answers it well enough, or clear enough. If the text is confusing, please let me know. I tried a couple routes of how to express it, and none of them seemed that clear.

You have written:
It appears to me that calling a JavaScript function from VBA is fairly impractical.
That is a misjudgment.
Javascript can be easily packaged as a Windows Script Component (WSC) and then invokved via COM, from VBA, Perl, VB6, or what-have-you.
Here's an example of packaging Javascript as a WSC and invoking it: https://stackoverflow.com/a/849970/48082
Therefore, your problem should be easily solvable.

Encrypting data with ruby decrypting with node

I want to encrypt some data in a ruby app and then decode it in a nodejs app. I have been trying to get this to work and now I am just trying to encrypt the same piece of data in both languages to get the same result but I can't seem to do it.
//js
var crypto = require('crypto');
var key = crypto.createHash('sha1').update('key').digest('hex');
console.log(key); // a62f2225bf70bfaccbc7f1ef2a397836717377de
var encrypted = "";
var cipher = crypto.createCipher('bf-cbc', key);
encrypted += cipher.update('text');
encrypted += cipher.final('hex');
console.log(encrypted); //outputs 4eafd5542875bd3c
So it looks like I get a hexadecimal string from the encoding.
#ruby
require 'openssl'
require 'digest/sha1'
c = OpenSSL::Cipher::Cipher.new("bf-cbc")
c.encrypt
# your pass is what is used to encrypt/decrypt
c.key = key = Digest::SHA1.hexdigest("key")
p key # a62f2225bf70bfaccbc7f1ef2a397836717377de
e = c.update("text")
e << c.final
p e # 皋?;??
Is there some sort of encoding issue that I am missing. I tried to base64 decode e but that didn't produce the same result as the node app. Any pointers?
UPDATE: So this is as close as a friend and I can get: https://gist.github.com/a880ea13d3b65a21a99d. Sheesh, I just want to encrypt something in ruby and decrypt it in node.
UPDATE2: Alright, the code in this issue gets me a lot of the way there: https://github.com/joyent/node/issues/1395

There are several subtle things that make this fail. The most important one - you are not specifying an IV in your code, so a random value will be generated for you. You would notice that you couldn't even decrypt your ciphertext within the same programming language this way.
So you need to provide an explicit IV to both implementations. But before I show you the code, some advice:
Key generation:
Blowfish operates on 64 bit blocks, its key size varies, but OpenSSL (which currently powers both Ruby's and node.js' cipher implementation) uses 128 bit by default, that is 16 bytes.
So your key violates two principles - the first: it's simply too long. It's the hex representation of a SHA-1 hash, which is 20 bytes * 2 = 40 bytes instead of 16. Most of the time this is fine, because the implementation truncates the values appropriately, but that is something you should not depend on.
The second mistake, much more severe, is that you use the hex representation instead of the raw bytes: big security issue! Hex characters are not random at all, so in effect you reduce the entropy of your input to half the length (because the underlying bytes were random).
A secure way to generate random keys is using OpenSSL::Random
key = OpenSSL::Random.random_bytes(cipher_key_len)
A third mistake is to keep your key hard-coded in the sources. It's a bad idea. The least you should do is to store it elsewhere on the file system, where access is tightly restricted. See also my answer to another question. The key should be stored out-of-band and only loaded dynamically within the application.
Cipher:
Blowfish grows old. It's still considered unbroken in the sense that brute-forcing it is the only way to break it. But a search space of 2^64 is not out of reach for resourceful attackers. So you should indeed move on to AES.
Padding:
OpenSSL pads using PKCS5Padding (also known as PKCS7Padding) by default. Ruby profits from this and my bet is node.js utilizes this, too - so you should be safe on this.
Now to the working solution. We need to generate an IV, Blowfish requires it to be 64 bit - 8 bytes. You will need rbytes to get secure random numbers in node. The IV may be hardcoded in your sources (it's public information, no security impact) - but it must be the same on both sides. You should pregenerate a value and use it for both node.js and Ruby.
/*node.js*/
var rbytes = require('rbytes');
var iv = rbytes.randomBytes(8);
/*see advice above - this should be out-of-band*/
var key = rbytes.randomBytes(16);
var encrypted = "";
var cipher = crypto.createCipheriv('bf-cbc', key, iv);
encrypted += cipher.update('text');
encrypted += cipher.final('hex');
Now the Ruby part:
require 'openssl'
c = OpenSSL::Cipher::Cipher.new("bf-cbc")
c.encrypt
# should be out-of-band again
c.key = OpenSSL::Random.random_bytes(16)
# may be public but has to be the same for Ruby and node
iv = OpenSSL::Random.random_bytes(8)
c.iv = iv
e = c.update("text")
e << c.final
puts e.unpack('H*')[0]

Your cyphertext will be some random looking bytes. Those bytes can be expressed as hex, Base64 or in other ways. It looks as if your ruby code is outputting the raw bytes. I suggest that you convert those raw bytes to hex to make your comparison.
Looking at your code, you should also change from Blowfish ("bf") to AES. Blowfish has a 64-bit block size and is now obsolete.
You would do well to explicitly specify padding, PKCS7 is common

OK. I want to thank everyone for helping me out. Basically this thread here answers my question: https://github.com/joyent/node/issues/1395. I am going to go ahead and post the two programs in case anyone else has to go through this rigamarole. Keep in mind this isn't mean to be hardcore secure, this is a stepping stone for ruby encrypting data and node decrypting it. You will have to take more steps to make sure higher security measures are taken.
The code is located at this gist: https://gist.github.com/799d6021890f34734470
These were run on ruby 1.9.2p290 and node 0.4.10