https://docs.expo.io/versions/latest/sdk/crypto/
Info: app is in react-native & Expo
Expo now provides a hashing method but only accepts String types for input.
Nodejs provides hashing of buffers/strings/arrays and can return the hashed value as a buffer as well.
The issue I am having is that I need to hash a buffer(uint8array) in my app with sha256. So I must find a way to convert it to a string, this causes issues because if I convert the buffer to anything else ex.(hexString,base64) my hash result is not equivalent to the exact value that nodejs crypto would provide.
I have also tried converting the buffer to utf-8/16 strings but this causes issues because the chars in this format can have multiple bytes(issues with the number being above 127). So this path was incorrect as well.
My hashes must be equivalent to the traditional nodejs createHash() results.
I am hitting a wall on this issue and not not find a way around it.
Related
Firestore can store 64 bit signed integers. However Javascript's number type has a 53 bit mantissa. How to read/write big numbers with Firestore without losing precision?
I tried:
Using BigInt: The Javascript SDK doesn't support it.
Using strings: This could do but I need sort operations for numbers.
For some reason the admin SDK has BigInt support, but the client library not.
Convert BigInt to a string and write it as a string to firestore. This modifies all clients you use to convert from string to BigInt and vice versa but will allow you to store large numbers as needed in the browser at least (due to JavaScript being 53 bit precision-ish). Not ideal but it works. If you need to query on that field in Firestore, I would then use a Cloud function to store the number in another field for querying. I realize this is not the ideal solution, but may help solve your issue in a pinch.
Finally, I would recommend doing is logging a feature request to the FireStore SDK for web to support BigInt.
I'm currently experimenting AES encryption using Google App Script, and I found out about cCryptoGS.
It feels weird, as like all ciphered texts seem to start with U2FsdGVkX1 (even though I change the part this is my passphrase in the example to something else very very different). I am not sure if I remembered correctly, I once tried AES in the past, but on Nodejs, and it looked just so much different, I'll get completely different text ciphered out even if I change only a single character in either my message, or my key.
Even in this post How is AES implemented in CryptoJS?, the ciphered text also starts with U2FsdGVkX1.
What I am asking is this: Is this cCryptoGS actually do what it claims to do? (i.e to apply AES encryption to a message)
Here's the website https://ramblings.mcpher.com/gassnippets2/cryptojs-libraries-for-google-apps-script/ There are also graphs on the site to show that Google App Script cannot handle complicated calculations well, so it looks legit, but the result seems to be so... weird... Since, overall AES seemed to be one of the best option to do encryption.
If this is indeed how AES should work, is there any way that I can make it seems more random? Thank you so much in advance, :(
Thank you very much in advance,
CryptoJS can process both passphrases and keys for encryption and decryption. Strings are interpreted as passphrases, WordArrays as keys, s. The Cipher Input.
cCryptoGS wraps the passphrase variant and supports the algorithms AES, DES, TripleDES and Rabbit, see Usage.
E.g. for AES, cCryptoGS/CryptoJS encrypts with AES-256, whereby a passphrase must be passed in addition to the plaintext.
Before encryption a random 8 bytes salt is generated and from passphrase and salt a 32 bytes key and 16 bytes IV is derived with the OpenSSL key derivation function EVP_BytesToKey().
The result is generated in OpenSSL format for compatibility with OpenSSL, which consists of the ASCII encoding of Salted__ followed by the 8 bytes salt and the actual ciphertext, with the entire expression Base64 encoded.
The Base64 encoding of Salted__ is U2FsdGVkX18=, where U2FsdGVkX1 is fixed (the last two characters depend on the 1st byte of the salt and can therefore change). Thus, any encryption starts with U2FsdGVkX1, but this does not reveal any information.
So yes, it is encrypted with AES-256, and the constant prefix U2FsdGVkX1 is not critical.
However, the key derivation function EVP_BytesToKey() is deemed insecure nowadays, especially with the parameters used by cCryptoGS/CryptoJS (broken MD5 digest and an iteration count of 1), s. e.g. here, 3rd part, so its use cannot actually be recommended (apart for compatibility maybe).
This applies to the wrapped functionalities that use passphrases for encryption/decryption. cCryptoGS also directly allows the use of CryptoJS functions, see CryptoJS direct, whose security is to be assessed individually.
The secure way is to pass key and IV directly, or when using a passphrase not to apply the built-in function EVP_BytesToKey(), but a reliable key derivation function like PBKDF2.
These variants are supported by CryptoJS, but apparently not by cCryptoGS, at least not by the wrapped functionalities.
Also note that at least the linked cCryptoGS sources seem to be based on CryptoJS version 3.1.2 which is from 2013, s. cCryptoGS sources (current CryptoJS version is 4.1.1).
I am currently working on a kotlin multi project solution.
I have one project defining some data classes and defining an api to access a mongodb. The objectId is created automatically. This project is using morphia:1.3.2.
Entries are stored using this function:
fun store(myClass: MyClass) = db.save(myClass).let { myClass.id?.toHexString() ?: "0" }
Now I'm using this project in a spring-boot kotlin project.
I created a small web page with some filters. These filters should be applied on my query. So far so good, everything is working.
The results of my query are returned via my Rest-controller without any conversions. In my web page I want to print the ObjectId foreach result.
But the ObjectId is not a String as it used to be, it is an object.
id:
counter:15304909
date:"2018-08-27T23:45:35.000+0000"
machineIdentifier:123456
processIdentifier:1234
time:1535413535000
timeSecond:1535413535
timestamp:1535413535
Is it possible to force morphia to return the objectId in the String representation? Or is there a on Option to activate the correct mapping? Or do I have to touch each result one by one and convert the object id to the hexadecimal string representation? I hope that there is a better, and quicker solution then this.
I am also not able to remap the object to a valid id, due to an java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986 exception. The request looks like this:
myClass?id={"timestamp":1535413631,"machineIdentifier":123456,"processIdentifier":1234,"counter":16576969,"time":1535413631000,"date":"2018-08-27T23:47:11.000+0000","timeSecond":1535413631}
I'm a little bit out of ideas, how to fix this issue.
Depending on your REST framework, you would need to provided a serializer for writing out that ObjectId as its String version, say. Most such frameworks make that transparent once it's configured so you need only worry about returning your objects out of your REST service and the framework will serialize properly.
I, personally, wouldn't muck about by trying to change how it's serialized in the database. ObjectId is a pretty good _id type and I wouldn't change it.
I've been working on something that encrypts a piece of data in Ruby using OpenSSL and decrypts the data in JavaScript using the JavaScript Forge library.
The (unsecure, but this is for research only) method of distributing the keys works fine, i.e., I can generate the keys in Ruby and put them into PEM format, pass the PEM to JavaScript and recover a working key in JavaScript, however encrypting the same string using the same key gives two different results, so encoding/decoding between the two obviously don't work.
Is there a good way of doing this?
The other problem is that passing a binary data string from Ruby to JavaScript without getting an incompatible type error requires some sort of conversion, for example, converting the encrypted data to hex, but working with this kind of information in the forge library is proving difficult.
I actually solved my own problem, in my original question
I just wasn't doing it right
For future reference, if you are using the ruby openssl RSA encryption and want to pass it to javascript, I recommend using the https://github.com/digitalbazaar/forge library for the JS side,
second, convert encrypted strings to hex using .unpack('H*')
Forge PKI library has a .hexToBytes() function, you can then use the forge .decrypt method and get back what you started
I would like to wrap a socket into another object which:
transforms output - e.g. turning strings into Base64
transforms input - e.g. turning Base64 into strings
(Note: my use case is not Base64 but is isomorphic to that and would significantly complicate the question.)
It is trivial to do this in the two direction separately - e.g. pipe socket into a Base64 decoder and write into a Base64 encoder which pipes into the socket.
I would like to generate a single new object from a socket, which could be written to and read from (via data events), yet perform the required transformations for both directions.
The solution needs to support Node 0.8.X and 0.10.X.
This seems to be one approach:
https://github.com/ajlopez/ObjectStream/blob/master/lib/objectstream.js