I need an RSA key pair for my web project and while there are some libraries I think it would be a good idea to rely on the browser (for security and speed) to generate the key for me. Is it possible to use keygen or something an other browser API to do so? I don't know how to get the keys from keygen. They seem to be generated on submit, but I don't want to send them to the server.
What you are probably looking for is something like Mozilla's DOMCrypt API proposal. It allows you to generate a key pair via window.mozCrypto.pk.generateKeypair() (window.mozCrypto is supposed to change into window.crypto later), you can get the public key and also encrypt or decrypt text with the private key. It will still not grant you direct access to the private key however, you only get a key ID.
Unfortunately, this API isn't supported by any browser yet. There is only a Firefox extension that can be used to test it, so that proposal is still in a very early stage. But I think that's the best you can get at this point.
I found this site, talking about generating RSA keys within the browser
There is a SSL-like protocol implemented in JavaScript : aSSL.
It uses a RSA algorithm for cryptography you could use their Keys generator.
Let's just say this is a scary idea due to the possibility of injecting code that steals the private key.
Related
I just started playing around with WebAuthn on localhost. I was given to understand that the signature value found in credentials.response.signature was signing credentials.response.clientDataJSON. However, for the same inputs / challenge for navigator.credentials.get I seem to be getting a different signature. My best guess is there is a timestamp or counter going somewhere into the value that is signed?
I can't seem to decode the signature or authenticatorData, which would really help me to visualize what's going on inside. I'm able to decode clientDataJSON as follows, anyone have sample code with which I code decode the other two aforementioned params?
String.fromCharCode.apply(null, new Uint8Array(credentials.response.clientDataJSON))
I also found when decoding clientDataJSON I get the occasional extra field in Chrome, which is a little annoying for my use case.
My goal is to get the user to produce the same signature or hash each time when authenticating the same PublicKeyCredential. Is there a way to do this? or are there other methods within the scrope of WebAuthn or outside of its scope to benefit from the biometric auth with which I can produce identical signatures or hashes from the same inputs?
Please forgive any misconceptions I might have about WebAuthn, I'm quite new to this amazing tech. I completely understand that this is not the original intended use of WebAuthn so a janky workaround may be needed.
My goal is to get the user to produce the same signature or hash each time when authenticating the same PublicKeyCredential.
This is actually a really bad idea. The whole purpose of signing a message with a random challenge is to avoid replay attacks. Otherwise, if an attacker somehow intercepts an authentication message, that message could simply be reused to impersonate the user.
I was given to understand that the signature value found in credentials.response.signature was signing credentials.response.clientDataJSON
That is not accurate. The signature signs authenticatorData + SHA256(clientDataJSON).
Both are variable. The authenticatorData contains a "counter" increasing each time the credential key was used to authenticate and clientDataJSON should (or must to be secure) contain a randomly server side generated challenge.
I can't seem to decode the signature or authenticatorData, which would really help me to visualize what's going on inside. I'm able to decode clientDataJSON as follows, anyone have sample code with which I code decode the other two aforementioned params?
The signature cannot be "decoded", it can only be "verified" given the adequate public key. For the other paramters authenticatorData and clientDataJSON , check out the following link at the bottom, it will decode them.
https://webauthn.passwordless.id/demos/playground.html
I also found when decoding clientDataJSON I get the occasional extra field in Chrome, which is a little annoying for my use case.
I'm not sure, I believe this is related to localhost testing.
If you want a small, fixed bit of data associated with a credential then you may wish to investigate the credBlob or prf extensions. Not all authenticators will support them, however. Many more will support prf but support for that in Chromium won't appear for a few more months. So there's not a great answer here yet, but it may work better than trying to fix the signature.
So, first things first, in general it depends on the signature scheme used whether the same signature will be produced when you use the same data as input. Check this question https://crypto.stackexchange.com/questions/26974/ where they discuss about it.
Now, coming back to WebAuthn (assuming that you use a signature algorithm that for the the same input will generate the same signature) let's look how the signature is generated. Here is a small code from my virtual authenticator that is responsible for generating the WebAuthn signature:
let authData = this._concatUint8Arrays(
rp_id_hash,
flags,
sign_count, // The signature counter will always increase
this._getAAGUID(),
credential_id_length,
credential_id,
cose_key
);
// Attestation object
let attestation_object = {'fmt': 'none', 'attStmt': {}, 'authData': authData};
// ...
// Generate signature
let client_data_hash = new Uint8Array(await crypto.subtle.digest('SHA-256', client_data));
let signatureData = this._concatUint8Arrays(authData, client_data_hash);
let signature = await Algorithms.Sign(this.private_key, signatureData);
You will notice that the data to be signed include the authenticator's signature counter which should increase each time you use the authenticator. This helps detecting replay attacks or cloned authenticator attacks (more info here).
Thus, it is not feasible to generate the same signature.
If you want to look more into what is going on under the hood of WebAuthn you can have a look into my WebDevAuthn project and browser extension that allows you to inspect the WebAuthn requests and responses.
How can i use ECDSA encryption algorithm with a private key to generate a digital signature in suitescript. Does netsuite support it and if not can i use it as an external library?
Thanks in advance
Since no one else has jumped in on this:
You should be able to do this in a script using the N/crypto/certificate module.
Basically you'd store your ECDSA cert under Setup/Company/Certificates
then you'd user certificate.createSigner with your cert id from above and the hash algorithm to use.
The Netsuite help form N/crypto/certificate has sample code
I found a solution to what I want to accomplish, but I have some queries too make sure I understand the concept correctly.
Note: I am still a newbie with Cryptography!
var key = CryptoJS.enc.Utf8.parse('7061737323313233');
var iv = CryptoJS.enc.Utf8.parse('7061737323313233');
How secure is the key and IV values when they displayed so openly (as shown above) in javascript you can view the values from browsers with inspect element or is my understanding of how the solution works wrong?
How does the process of exchanging keys between application and service work?
To enable message-level encrpytion in Pubnub, one would include the cipher key when instantiating PubNub on the client.
var pubnub = PUBNUB({
publish_key: 'my_pubkey',
subscribe_key: 'my_subkey',
cipher_key: 'my_cipherkey'
});
The PubNub docs then state:
Never let your cipher key be discovered, and be sure to only exchange it / deliver it securely. On JavaScript, this means explicitly don't allow anyone to View Source or View Generated Source or Debug to enable viewing your cipher key.
Exactly how would one completely obfuscate a cipher key in a web page? It is not possible to completely prevent someone from viewing the source, only make it inconvenient. Any encryption/decryption routines on the client can also be identified fairly easily.
What exactly is the suggested route we should take here?
I am not familiar with pubnub, but in cases similar to this, you can create a hash or some other reference that points to the secret on your server. So the hash is shared between client/server, and the server references the hash as your key.
You have not said what your server side language is, but there are a number of different hashing mechanisms available, SHA-1 or similar is recommended https://en.wikipedia.org/wiki/SHA-1
That's exactly the point: you cannot ever publish your cipher_key on the web under any circumstances. Websites may use their API given the other (public) keys, but the cipher_key must only be used from environments that are secure.
I'd like to use Firebase to make publicly-readable data whose location is difficult to guess. So, to give someone access to the data stored in "element [element ID = X]", I'd like to just send them "X", instead of sending them "X" along with a security token crafted to give them access to the element. Firebase's push() and childByAutoID seem like a natural fit: I can grant public read access to all individual elements, but deny public listing. My code will be blissfully free of token and random number generation. The automatically generated ID is supposed to be unique, and thus should be difficult to guess.
From looking at Firebase.js, it appears the first 8 characters of the automatically generated ID are based on the current timestamp, and the next 12 characters are randomly generated using Math.random(). I assume that the iOS framework does the same thing, and although I can't see the code, the library links to both SecRandomCopyBytes and arc4random.
For my purposes, this looks good enough, but has anyone seen guidance from Firebase on whether we can count on this behavior? I would hate to build code that assumes these names are relatively strong random strings and then have that assumption violated when I upgraded to a newer version of Firebase.
The purpose of the auto-generated IDs provided by Firebase is to allow the developer to create a chronologically ordered list in a distributed manner. It relies on Math.random and the timestamp to generate an ID unique to that client.
However, if you're going to use the auto IDs as security keys, it may not be the best idea depending on how secure you want your system to be. Math.random is not a cryptographically secure random number generator and since push() relies on it, the IDs generated by it aren't either.
The general concept of giving a user access to some data in Firebase if they know the key is a good one though. We have an example of using this type of security rule, but instead of using push IDs, we use a SHA-256 hash of the content itself (in this particular case, they are images). Hashing the content to generate the keys is more secure than relying on push() IDs.