Disclaimer: New to cryptography.
I have an external process that uses OpenSSL to encrypt data, which right now, uses a salt.
An iPhone app grabs that data from a server, downloads it to the app's documents directory, and needs to decrypt it. The iPhone OS does not include the OpenSSL library. You can build it yourself, but it's difficult and tricky. The "easiest" solution I've found, thanks to Stackoverflow's help, is to use CommonCrypto/CommonCryptor.h which is part of the Security Framework.
But the C function to decrypt data needs an iv to correctly decrypt.
Is there a way to derive the iv from the encrypted data (which, to me, seems like it would negate the extra security)? Or do I need to, first, specify the iv somehow and let the iPhone app know what it is? Or, just don't use a salt?
Edit1: To clarify, I'm using OpenSSL to encrypt text in a data file. A script using OpenSSL encrypts the text, uploads to Dropbox, then the app downloads the file from Dropbox, parses it, and attempts to decrypt the text.
Edit2: Yes, I'm using the OpenSSL command line utility with the -pass option.
The IV should be chosen randomly for each message you encrypt. I assume you are using the OpenSSL command line utility, openssl enc, but it's not clear whether you are using password-based encryption (the -pass and -salt options) or specifying the key explicitly (the -K and -IV options).
For the best security, I recommend that you use the -K option, and randomly generate a new IV for each message. Send the IV along with the ciphertext. For example, you could append the ciphertext to the IV in one file, and then strip the IV from the beginning of the file when you are ready to decrypt.
The IV can be public; you don't have to hide it. The important thing is that you use an unpredictable IV for each message.
The iv can not be derived from the encrypted data, it must be either agreed on outside of the communications between the two sides or made public. Also depending on the encryption mode it may not be required, but CBC is the most common and does require an iv. The iv basically makes it harder to glean any information from the first block.
In your case you just need to figure out the iv, either it is static and just hard-code it or it it is transmitted, possibly in a pre-amble, figure out how to extract it from the data.
The iv may be as simple as 0.
One problem with SSL is trying to capture the packets. That can be done easily with the app Charles (link here), it has a free trial. I use it regularly.
Personally I use to compile OpenSSL for a wide variety of functionality, try this tuto http://www.x2on.de/2010/07/13/tutorial-iphone-app-with-compiled-openssl-1-0-0a-library/ really is simple.
Cheers!.
Related
Background
Yahoo Finance recently (Nov-2022?) started encrypting their returns from queries such as: curl --silent --output - https://finance.yahoo.com/quote/t.
I found some Python code that will decode this in https://github.com/ranaroussi/yfinance/blob/main/yfinance/data.py#L49
Since Python is an Algol-like language, I was hoping it would be a quick port.
Here is where I hit a snag: https://github.com/ranaroussi/yfinance/blob/main/yfinance/data.py#L82
I was hoping for some relief from an existing perl module, such as Crypt::OpenSSL::FASTPBKDF2.
I know just enough about cryptography to hurt myself.
My question(s):
Is there a straightforward port for the Python function EVPKDF? It seems so close, except for the hashAlgorithm="md5" portion of EVPKDF(password, salt, keySize=32, ivSize=16, iterations=1, hashAlgorithm="md5").
The Crypt::OpenSSL::FASTPBKDF2 module doesn't seem to support md5. I know that md5 was defeated over a decade ago, but it seems to be what Yahoo is dishing out, based on the Python code.
Any thoughts are welcome.
My goal is to get the data, and I am not above using a system("openssl kdf..."); call. Not this time, anyway.
The UUID standard has several versions. Version 4 for example is based on a completely random input. But it still encodes the version information and only uses 125bits of the possible 128 bits.
But for transferring these via HTTP, it is more efficient to encode them in BASE64. There are libraries for this (https://github.com/skorokithakis/shortuuid).
But what I am wondering: Is there an alternative standard for shorter ID-strings? Of course I could slap together a version-byte + n random bytes and encode them BASE64, having my own working 'short, random ID scheme', but I wonder if there is any alternative that someone already specified before I make my own.
There is no standard for anything shorter.
Numerous folks have asked the same question and all come to the same conclusion: UUIDs are overkill for their specific requirements. And they developed their own alternatives, which essentially boil down to a random string of some length (based on the expected size of their dataset) in a more efficient encoding like base64. Many of them have published libraries for working with these strings. However, all of them suffer from the same two problems:
They cannot handle arbitrarily large datasets (the reason UUIDs are so big)
They are not standardized, which means there is no real interop.
If neither of these problems affect you, then feel free to pick any of the various schemes available or roll your own. But do consider the future costs if you discover you're wrong about your requirements and whether the cost of having to change justifies whatever minuscule advantage in space or complexity you get by not using a proven, universal system from the start.
I have just found https://github.com/ai/nanoid
It it not really a 'standard', but at least not an arbitrary scheme that I would come up with myself. It is shorter through smarter encoding (larger alphabet) and faster.
A quick and dirty alternative is mktemp, depending on your requirements for security, uniqueness and your access to a shell.
Use the form mktemp -u XXXXXXXX
-u: dry-run, don't create a file
XXXXXXXX is the format, in this case eight random characters
$ echo `mktemp -u XXXXXXXX`
KbbHRWYv
$ echo `mktemp -u XXXXXXXX`
UnyO2eH8
$ echo `mktemp -u XXXXXXXX`
g6NiTfvT
I'm trying to use Filter::Crypto module, but I'm little bit struggling with it. I would like to encrypt a script
crypt_file script.pl > encrypted_script.pl
and then use that encrypted script on another machine.
When I use
pp -f Crypto -M Filter::Crypto::Decrypt -o encrypted_script encrypted_script.pl
created binary works fine - it contains key for decryption. But I want to use just the encrypted_script.pl file. I would like to provide fully functional encrypted perl script, which nobody would be able to decrypt (easily). Is it even possible?
You're talking about digital rights management, although you may not know it.
Encrypting something so it's really hard to read is relatively easy. Doing so at the same time as allowing someone to read it, but only when you say so is really difficult. (as in, basically impossible without control over the target infrastructure, at which point it's largely academic anyway)
That goes double when you're trying to use an interpreted language like perl, because obfuscation tricks have to be de-obfuscated before you can run them.
The module explains some of this, and has some mechanisms to make it slightly harder, but at a pretty fundamental level - it's impossible to do exhaustively.
I've a very modest usage of OpenSSL in my application.
Basically, I'm merely doing these two things:
RSA decryption: Initializing RSA key with RSA_new, BN_bin2bn, RSA decryption with RSA_private_decrypt, and releasing the key.
AES decryption: using EVP__DecryptInit( ... EVP_aes_128_cbc ), EVP_DecryptUpdate and EVP_DecryptFinal.
That's all. Despite this very modest usage, the executable size is over 1MB, with about 1,200 different symbols coming from the OpenSSL library. These includes function which are obviously not in my code tree, such as ASN1_, SHA1_, EC_*, PKCS7, etc.
I'm linking with static library of OpenSSL for the iPhone Android and Windows. On the mobile platform the footprint is an issue. My linker is supposed to leave out unreferenced functions, so these symbols seems to be referred somehow.
Is there any way to take smaller pieces of OpenSSL to reduce the executable size?
u.
Symbols from OpenSSL includes which are being referenced directly or indirectly.
If there is something left out by the linker (since it is automated tool and can miss something), then you can try the following:
Build the OpenSSL with the only functions you required.
This will give you idea about the dependencies which you are using from OpenSSL.
For this, start with top-level functions you need. You will get linker errors of the functions you need. Then include those functions. After few iterations, you will get minimal OpenSSL library.
This has serious problem when you need other function to use.
Also, you can look into the compiler options related to optimization especially for executable size.
I'm developing a firefox extension and I'd like to provide automatic update to my beta-testers (who are not tech-savvy). Unfortunately, the update server doesn't provide HTTPS. According to the Extension Developer Guide on signing updates, I have to sign my update.rdf and provide an encoded public key in the install.rdf.
There is the McCoy tool to do all of this, but it is an interactive GUI tool and I'd like to automate the extension packaging using an Ant script (as this is part of a much bigger process). I can't find a more precise description of what's happening to sign the update.rdf manifest than below, and McCoy source is an awful lot of javascript.
The doc says:
The add-on author creates a public/private RSA cryptographic key pair. The public part of the key is DER encoded and then base 64 encoded and added to the add-on's install.rdf as an updateKey entry.
(...)
Roughly speaking the update information is converted to a string, then hashed using a sha512 hashing algorithm and this hash is signed using the private key. The resultant data is DER encoded then base 64 encoded for inclusion in the update.rdf as an signature entry.
I don't know well about DER encoding, but it seems like it needs some parameters.
So would anyone know
either the full algortihm to sign the update.rdf and install.rdf using a predefined keypair, or a scriptable alternative to McCoy
whether a command-line tool like asn1coding will suffise
a good/simple developer tutorial on DER encoding
Things have moved since last year:
welcome to uhura (and they are listed on the official MDC McCoy page)
uhura -k signature.key yourextension.xpi http://yourupdateurl
Additional advantage is that you can generate, backup, move your own crypto keys without being bound to mozilla's DB. Only drawback is: Perl based (how painful to fix missing dependencies, with or without CPAN)
As a side note, I had almost started writing my own python-based script, but could not find any RDF-aware signing lib; or, actually, even XML-signing libs are crap for python (but hey, XML-DSig is inherently evil, isn't it). Why did Mozilla pick RDF for the extension manifest?
not sure if you already found solution, but McCoy tool has a command line patch.