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.
Related
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.
So the April 1, 2013 xkcd Externalities web comic features a Skein 1024 1024 hash breaking contest. I'm assuming that this must be nothing more than a brute force effort where random strings are hashed in an effort to match Randall's posted hash? Is this correct?
Also, my knowledge of Skein hashing theory is virtually non-existent but being a halfway decent programmer I was able to download and run both SkeinFish (C#) and Maarten Bodewes Skein implementation (Java) locally in 1024 1024 mode with some input strings. The hashes that they gave, however, were different than the hash that xkcd returned for the same input. This may be an extremely naive question but do different Skein implementations give different hashes? And what Skein implementation is xkcd using?
Thanks for pardoning my ignorance!
There are several different iterations of the skein algorithm. XKCD is using version 1.3, which is also the most recent. Sources can be found here (look for "V1.3")
Interestingly enough, this brute-force method is the same one employed by Bitcoin to "mine" bitcoins. The big differences are the hash algorithm (SHA-256 in that case) and the target hash (which is dynamically determined to be any hash starting with a certain number of zeros.) It takes a lot of work to discover the hash, but once it has been found it is trivial to verify the source bits and that the resulting hash meets the criteria.
Here's the source code the Stanford team used. We ran this on about a hundred 8-core EC2 servers for a while, but not the whole competition.
https://github.com/jhiesey/skeincrack
If you were hashing non-alphanumeric characters (spaces, punctuation, etc.), you may have been getting different results due to HTML form encoding. The "enctype" attribute on the form XKCD was hosting was "application/octet-stream", which according to https://developer.mozilla.org/en-US/docs/HTML/Element/form is not a browser-supported standard. I assume the browser falls back on the URL-encoding type when it sees one it doesn't recognize.
I observed the string "=" being submitted URL-encoded in Chrome, and returning a different hash than what I got locally with the latest pyskein. But when I submitted it with this curl command line (no longer works), I got the expected hash:
curl -X POST --data-binary "hashable==" "http://almamater.xkcd.com/?edu=school.edu"
The Stanford code in another answer does the same thing, and they apparently had some success. I never got any random data to locally hash to a better score than even my own school, so I never got a chance to test thoroughly how to pass arbitrary data in properly. I don't know what the exact behavior was (e.g., perhaps if you omitted hashable= the server would detect that and just hash the whole POST body), but it may have intentionally been a little tricky as part of April Fool's.
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.
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!.
I seen MD5 and SHA1 hashes on the net to verify files. What are common hashes used on the net and other programs? This is to verify a file not to hash a pw.
I've used some hash functions from the following site before - they are usually pretty quick, and full code is given on the website, and a description of each of the functions and their strengths/weaknesses:
http://www.partow.net/programming/hashfunctions
Examples of the hashes given are - Kernighan and Ritchie (from "The C Programming Language") and the Knuth hash (from "The Art Of Computer Programming Volume 3").
To verify files you can use cyclic redundancy checks, such as CRC32, which have been as far as I know the de-facto standard for hashing files for a long time in the IT, if you want to look at other stuff than MD5/SHA.
See also this list of checksum algorithms for more ways to check your files.
I never used anything else than MD5. Add a Salt if you use it for passwords.
Wikipedia has a list of hash functions, broken up into different types (checksums, non-crypto, crypto etc).
The Apache Foundation (among others) uses PGP Signatures.