I'm trying to convert some code from LB2 to LB3 and have hit a bit of a wall.
I have a very basic 256-bit RSA public key which I use with LB2 but can't seem to load into LB3.
The key is basically just a block of 41 bytes which I can load by simply calling TLbRSASSA.PublicKey.LoadFromStream. I'm using the key for some simply signing.
I just can't get this key to load into LB3 at all no matter what I do. If I use LB3 to generate a similar 256-bit key and save it to a file, the format is different, with what looks like a header containing "LockBox3" and so forth.
Can anyone offer a simple explanation of how to load this 41-byte public key into LB3 so I can continue to verify signatures with it?
Many thanks
LB2 keys are not compatible with LB3 keys.
If you want to upgrade to LB3, you will need to generate new keys.
Related
I'm following Apple's guide towards composing a CloudKit Web Services request. The bit I'm having trouble with is Step 2, under "Authenticate Web Service Requests":
Compute the ECDSA signature of this message with your private key.
Before getting to this point, I generated my certificate, a .pem file, which when opening it in a text editor shows me my private key, so I have that in string format too.
I've also followed the steps for generating what it refers to as a message, which I now have as a string.
So given that I have a private key, (or the .pem file if required), and a message as a string, it should in theory be fairly simple for me to get a ECDSA signature of the message, computed with my private key. But here's where I'm struggling. Libraries that I've found online seem to take a far more complicated approach, with different moving parts, no reference to a .pem file and talk of generating new public/private keys.
Any help with this step would be greatly appreciated.
It appears that the documentation and the actual API for Ruby’s OpenSSL EC support are both currently rather lacking. In particular, in Ruby <= 2.3.1 the OpenSSL::PKey::EC doesn’t follow the same API as RSA and DSA keys for signing and verifying. What you would want to do, but currently can’t with EC keys, is this (all the code here assumes you have called require 'openssl' somewhere):
# Get the key, here I'm reading the file
priv_key = OpenSSL::PKey.read(File.read('eckey.pem'))
# This should be the appropriately formatted string
data = "some data to sign"
# The hash algorithm, I assume SHA256 is being used
digest = OpenSSL::Digest::SHA256.new
# This doesn't work in 2.3.1, but does in 2.4.0-preview1
signature = priv_key.sign(digest, data)
As I note in the comments, this does work in Ruby 2.4.0-preview1, but that’s likely not much use to you.
To get it working with current Ruby, you need to do something like this:
# As before:
priv_key = OpenSSL::PKey.read(File.read('eckey.pem'))
data = "some data to sign"
signature = priv_key.dsa_sign_asn1(OpenSSL::Digest::SHA256.digest(data))
Both these techniques give you a binary string. I think you will need to base64 encode it before adding it as your request header.
To extract the public key to check the signature verifies is also a bit tricky (although you could just use the openssl command line and read in the file). The public_key methods returns an OpenSSL::PKey::EC::Point object rather than an actual key, so we need to recreate one from the private key. The verify method does work on Ruby 2.3.1:
pub = OpenSSL::PKey::EC.new(priv_key.group)
pub.public_key = priv_key.public_key
data = "some data to sign"
digest = OpenSSL::Digest::SHA256.new
puts pub.verify(digest, sig, data)
The Apple page doesn’t appear to specify the hash algorithm to use, but from what I’ve seen it looks like SHA-256 is right. (Also I could have got this completely wrong and Apple are using a completely different format. I’d be keen to know whether or not this code works you you).
I am using 'RijndaelManaged' and 'CryptoStream' classes in C# to encrypt files. Before encrypting the files, i want to check whether the file is already encrypted or not.
I tried using File.GetAttributes() method to check for Encryption but it is not working.
I need some tips on ways i can check whether the file is already Encrypted or not.
Without any sort of custom headers, the only way to be absolutely sure the file is encrypted is to attempt to decrypt it.
If you attempt to compress the file and it gets smaller, then it is extremely unlikely to be encrypted. If there is a non-uniform distribution of byte values (including plain text!), then it is unlikely to be encrypted.
Those heuristics depend on proper execution of the encryption. If AES is applied to a file one block at time, then patters can emerge in the result, but since you are using CryptoStream this shouldn't be a problem.
If your own code will always be used to encrypt and decrypt the files, then you should consider adding a custom header that indicates it is an encrypted file.
Suppose I have a file F containing ciphertext X, which is the enciphering of plaintext Y with key Z.
I wish to ensure that the plaintext Y can only be determined by someone who possesses both key Z and key Q. (I can think of a number of reasons why I might wish to do this.)
I therefore wish to encrypt the already-encrypted file with key Q.
You're telling me that your system wishes to detect that F is already encrypted, and then refuse to encrypt it with key Q?
That seems like a bad idea. I might want to encrypt the file with key Q irrespective of whether it is already encrypted with key Z or not.
You have to inspect the file and look for structures, or byte strings that would not be there if the file is encrypted. You would need a separate test for every type of file you are dealing with.
If the file is encrypted it will appear as a stream of random bytes. You can:
Attempt to open the file and/or confirm that it is of the expected format (JPG, ZIP, whatever). If the file matches a known format then you know it is decrypted.
Attempt to decrypt the file if you have the key, then repeat the previous step. If it now matches a known format then you know it is (was?) encrypted.
I would suggest rename the encrypted file at encryption process with something with you can check it when you want to decrypt it.
Set your encrypt method bool type, if the file can decrypt, then the method return true which indicates the file is encrypted, otherwise the method throw exception and return false which indicates the file cannot be decrypted, or say the file is not encrypt.
I've been going around in circles from Apple's CCCrypto docs, frameworks and other SO answers and am not making any headway.
I think I need to figure out how to get a IV from an encrypted string that I receive.
I receive a JSON payload which contains a String. That string is encrypted in AES-256-CBC. (From a Laravel PHP instance that I think uses OpenSSL). The string itself, decrypted, is another JSON object.
I have a pre-defined key.
The string I receive looks something like:
eJahdkawWKajashwlkwAkajsne8ehAhdhsiwkdkdhwNIEhHEheLlwhwlLLLLhshnNWhwhabwiIWHWHwh=
(but is a lot longer).
I'm trying to use this answer here: Issue using CCCrypt (CommonCrypt) in Swift
But am a) unsure if I'm properly converting the string to data and b) how to get the IV (initialization vector) from the string I receive.
Using that answer I do get "success" however when I try to pass it to the NSJSONSerailizer I never got a good result (it always fails) but I do get data out - I think it's garbage.
Edit:
I really mis-understood my original problem - I was receiving a base64 encoded string that I needed to decode into JSON (which went fine). Then using the linked answer and importing CommonCrypto I thought I'd be able to get usable data but I am not. #Rob Napier 's answer is extremely helpful. I think my problem is that the instance of laravel in question is using OpenSSL.
There is no really commonly used standard format for AES encrypted data (there are several "standard formats" but they're not commonly used....) The only way to know how the data you have is encrypted is to look at the documentation for the data format, or failing that, the encrypting code itself.
In good encryption formats, the IV is sent along with the data. But in many common (insecure) formats, there is a hard-coded IV (sometimes 16 bytes of 0x00). If there's a password, you also need to find out how they've converted the password to a key (there are several ways to do this, some good, some horrible). In a good format, the key derivation may include some random "salt" that you need to extract from the data. You'll also need to know if there is an HMAC or similar authentication (which might be stored at the beginning or the end of the data, and may include its own salt).
There just isn't any good way to know without documentation from the sender. Any decently encrypted format is going to look like random noise, so figuring it out just by looking at the final message is pretty hard.
If this comes out of Laravel's encrypt function, then that seems to be ultimately this code:
public function encrypt($value)
{
$iv = mcrypt_create_iv($this->getIvSize(), $this->getRandomizer());
$value = base64_encode($this->padAndMcrypt($value, $iv));
// Once we have the encrypted value we will go ahead base64_encode the input
// vector and create the MAC for the encrypted value so we can verify its
// authenticity. Then, we'll JSON encode the data in a "payload" array.
$mac = $this->hash($iv = base64_encode($iv), $value);
return base64_encode(json_encode(compact('iv', 'value', 'mac')));
}
If this is correct, then you should have been passed base64-encoded JSON with three fields: the IV (iv), the ciphertext (value), and what looks like an HMAC encrypted using the same key as the plaintext (mac). The data you've given above doesn't look like JSON at all (even after base-64 decoding).
This assumes that the caller used this encrypt function, though. There are many, many ways to encrypt, though, so you need to know how the actual server you're talking to did it.
snatching my hair to fix this problem but I can't.
I am parsing id in url to pull data on next page according to that id. So rather than parsing id=123 I encrypted it something like process.php?token=TG4n6iv_aoO7sU3AngFY4WLSppLvueEoh-MnYE6k7NA, and decrypted it on process.php page by collecting it with $_GET, before using it in sql query. This is not proper URL, I need url like process.php?token=9878799889 and I need to decrypt this 9878799889 on process.php which would give me my original user id.
So here I can not use md5 or base64_encode which give me ugly string.
What would be best thing to do here?
id is unique so generated long digits should be unique as well and not easy to guess.
Right now I am using encrypt logarithm with salt. Actually want to parse like www.sitename.com/process/token/9878799889..this can be achieve with .htaccess so not worried about it..
Any help will be much appreciated..
What you could do is add an association table in your databse, which would contains a UUID as primary key (a randomly generated number) and your true ID reference (and other information you may want to store there, like a "valid until" date or other things...)
You'd have to generate the entry in that table as you parse the UUID
let's say INSERT INTO uuid_table (uuid, real_id) VALUES (9878799889, 123);
now when you process the url process.php?token=9878799889
you would only have to SELECT real_id FROM uuid_table WHERE uuid=9878799889;
it would retern the read id 123
You should also DELETE FROM uuid_table WHERE uuid=9878799889 when you're done.
Note that it would also work with md5 or base_64, but indeed it makes the url uglier.
I'm interested in url signing (e.g. http://.../?somearg=value&anotherarg=anothervalue&sig=aSKS9F3KL5xc), but I have a few requirements which have left me without a solution yet.
I'll be using either PHP or Python for pages, so I'll need to be able to sign and verify a signature using one of the two.
My plan was to use a priv/pub key scheme to sign some data, and be able to verify that the signature is valid, but here's where it gets complicated:
The data is not known when the verification is happening (it is not just somearg=value&anotherarg=anothervalue)
My first instinct was to use OpenSSL, e.g. with a RSA keypair, to do something along the lines of signing by: openssl rsautl -sign -inkey private.pem -in sensitive -out privsigned and verifying based on the privsigned data and key ONLY: openssl rsautl -verify -inkey public.pem -in privsigned -pubin.
Using PHP's openssl_get_privatekey() and openssl_sign() signs the data just fine, but I need to know the (decrypted!) data in order to verify (which I will not have): openssl_get_publickey() and openssl_verify($data, $signature, $pubkeyid); from http://php.net/openssl_verify.
Or am I missing something here?
So I looked into HMAC, but although many hash function are available in both Python and PHP, I'm baffled as to how I'd go about verifying the hash.
PHP's hash_hmac() allows me to create a hash using a "key" (or in this case a string-key). But how do I go about verifying that a hash is valid (i.e. &sig= hasn't just been manually put in by the end user &sig=abcdefg1234.
So to sum up (sorry for the long question): How can I verify that a signature/hash has been made by my server's (cert/string)key (given I can not verify by redoing the hash of said data)? And do you have any preferences as to which route I should chose, Priv/pub-key or HMAC?
Any pointers big or small is greatly appreciated!
Thanks in advance,
Josh
As Henning Makholm pointed out, HMAC is a better choice than public key. There are some best practices you should consider for your particular scenario that will impact your choices:
Do you want to consider the hostname and scheme (http/https) in the signature? Maybe.
Do you want to consider the path in the signature? Probably.
Do you want to consider the query string in the signature? Probably.
Do you want to normalize the argument order and escaping prior to signing? Usually not.
Do you want to embed signature time etc (to create time-limited URLs)?
Do you want to tie the signed URL to some other user state, such as cookie?
Are you using user-generated or user-visible content directly in the HMAC? If so, you should "salt" the key using a value that is randomized for each request.
When computing the signature, you'll need to encode it in a URL-friendly way (base64 and base32 are popular choices) and choose an HMAC algorithm (such as SHA-256), and decide how many bits of the signature you want to keep (truncating the HMAC value in half is usually safe). If you choose base64, beware of the different alphabets used by url-safe vs non-url-safe implementations.
Here is a pseudocode implementation (w/o error checking or salting etc) for signing path + query string:
const secret = ...;
def sign(path, querystring):
return path + "?" + querystring + "&sig=" + url_encode(base64_encode(hmacsha256(secret, path + "?" + querystring).truncate(16)))
def verify(path, querystring):
querystring_without_sig = remove_query_parameter(querystring, "sig")
sig = base64_decode(url_decode(get_query_parameter(querystring, "sig")))
if hmacsha256(secret, path + "?" + querystring_without_sig)[:16] != sig:
raise "invalid sig"
HMAC SHA256 is recommended and is available in all common languages.
Java:
Mac mac = Mac.getInstance("HmacSHA256");
mac.init(secret);
return mac.doFinal(value.getBytes());
Python:
hmac.new(secret, input, hashlib.sha256).digest()
PHP:
hash_hmac("sha256", value, secret);
HMAC is a symmetric algorithm, so there is no separate creation and checking algorithm. To check, you simply compute the hash as it should have been computed originally, and check that the result equals what you actually got from the client. The security rests on the HMAC key only existing on your server.
Unless you need the signatures to be verifiable by someone who doesn't know the secret key, HMAC is probably a better choice than public-key systems, for reasons of efficiency. It can take several milliseconds to create or verify a public-key signature (some years ago I timed one implementation at 15 ms per operation), whereas HMAC is quite fast.
(Oh, and you cannot verify any kind of signature without knowing the data it's supposed to sign. That wouldn't make any sense, as far as I can see).
If you want to use HMAC and Python, then:
$ pip install ska
On the client side
from ska import sign_url
signed_url = sign_url(
auth_user='user',
secret_key='your-secret_key',
url='http://e.com/api/'
)
Produced URL looks like as follows.
http://e.com/api/?valid_until=1378045287.0&auth_user=user&signature=YlZpLFsjUKBalL4x5trhkeEgqE8%3D
On the server side
Note, that in example below request.GET is given as example. It will most likely vary from what's used in your framework (unless you use Django).
from ska import validate_signed_request_data
validation_result = validate_signed_request_data(
data = request.GET, # Note, that ``request.GET`` is given as example.
secret_key = 'your-secret_key'
)
The validate_signed_request_data produces a SignatureValidationResult object, which basically holds two properties:
result (bool): True if data is valid. False otherwise.
reason (list): List of strings, indicating validation errors.