I'm looking for a good way to encrypt ePub files. DRM is a too expensive option and not really needed: so good encryption will do the job but I'm not sure what are the standards/the way to go.
I get 'clean' unprotected ePub files which I can encrypt serverside. Then they can be downloaded with an iOS client. If I put the decrypt logic in the app, it will be unsafe, right? The user may not have access to the clean ePub file.
When working with an encryption key, it also have to be downloaded by the client, so unsafe too, right?
What's a right way to do this? For example: how is Spotify doing this?
Related
I want to encrypt a code I wrote.
After a quick search, I have found recommendation on GPG.
Is encrypting code with GPG common and standard? I have read that it is supposed to be for e-mails.
If not GPG, what should I use?
You can use GPG for signing, encrypting, and decrypting texts, e-mails, files, directories, and whole disk.
But the common way to secure your code is code obfuscation and not encryption.
Obfuscation creates ambiguous code, which makes reverse engineering difficult.
You can use spacial obfuscator for your programming language which is a programming tool that is used to transform readable code into ambiguous code without affecting code functionality.
I want to encrypt the files that are uploaded by users of a web application.
The files need to be encrypted and decrypted individually.
Are there advantages to encrypting the file using an external tool than inside the application?
For example calling gpg, crypt or 7zip (or any other tool) immediately after a file was uploaded.
Upon request for a retrieval, call them again to decrypt, then serve the file.
I thought this may have performance advantages as well as the fact that encryption can be outsourced to a potentially more robust and well trusted application than the library available in the programming language.
Launching an tool creates a new process every time, which can impact scalability. There are libraries as respectable as tools, some of them from the same codebase.
First of all, you shouldn't implement your own crypto. That said, the alternatives don't look that different to me. Surely you can use GPG either in-process (called via an API) or out-of-process (with parameters passed on the command line). Then the considerations come down to the usual engineering ones of performance, robustness, etc and really have nothing in particular to do with cryptography.
I've a dataconfiguration.config encrypted file for an application on ASP.NET Framework 3.5
I need to change my connection string, how can i decrypted and read this file?
Security it's not an issue, I'm on a development enviroment.
Any tip will be preciated.
Thanks.
A common way to encrypt ASP.NET configuration sections (such as ConnectionStrings) is to use Protected Configuration. However if your file does not read as XML, this method was not used or was not the only level of encryption used. It sounds like maybe there was a third party tool involved.
If I were you, I would probably create a new config file, and find everywhere in the project the old config file was referenced to point things at the new file.
If that is not possible, maybe you'd have better luck posting a question in a general cryptography category or doing some searches on the subject. I know some encryption can be identified by look at the encrypted data. Some encryption schemes are designed specifically to hide that though. Good luck.
As SWFs are notoriously easy to decompile, If I am distribution SWF with secure keys inside or some valuable peace of code, how should I secure it?
EDIT:
I think it is very easy to decompile SWF because it is byte coded to SWF and then jitted to run. This same happens with Java compilation and execution. Does this mean even java codes are not secure enough?
Why, then, Java is far more trusted and reliable and SWF is not considered secure anywhere?
The short answer is DON'T do that. Even with code obfuscation, or storing data in a byte array, there is NO WAY to prevent someone who is determined (and able) from getting anything and everything from your source.
What type of secure key are you trying to put into your swf? What will it be used for?
Key theft is probably out. If someone is dedicated to it, they will find a way, despite obfuscation, to get at the key.
Code protection & IP is another matter. Here obfuscation and "encryption" (i.e. whatever is done to prevent decompilers from functioning properly) are valid methods. If your code is sufficiently obfuscated it would be very hard for competitors to steal it or to learn too much about your code's internals. It's just not feasible. Heck, trying to learn someone else's code is hard enough as it is, and so trying to decipher code that looks like loc_12312++; if (loc_23423) loc_4345(); is just not worth anybody's time.
I strongly recommend that if you care about the IP in your application's design and internal workings, you use a tool like SecureSWF to obfuscate the code as much as you can. Unlike with license keys, here the protection isn't as weak as its weakest link - the more you obfuscate the harder you make it to steal your IP.
Edit
My experience with Flex obfuscation tools is that you have to tweak the obfuscation quite a lot to get what you need. Simply telling the obfuscation software to rename all variables, classes, etc. is bound to break your application, unless it's really really simple. So you have to choose which packages and classes to obfuscate and tweak various other parameters in order to get a working application.
Once it's obfuscated though, it's pretty hard to decipher, in my opinion. Here's a sample, just to get a perspective:
I'd rethink what you're putting in the SWF. But that said, if you see no other options, NitroLM has a SWF encrypter which allows you to encrypt the SWF. Sharify is an alternative service.
In theory you could write your own mechanism for encrypting a SWF and your own "EncryptedSWFLoader." Of course, I suspect that any key in the SWF will most likely be something you need to send back to a server; and having someone sniff the packets--with a tool such as ServiceCapture or Charles--is more likely to be a source of "key leakage" than decrypting the SWF.
You won't get real security, but to make decompilation a little harder, use a code obfuscation tool, like doSWF, and/or store important data as byte array.
Edit: Ignore this answer: didnt spot the 'distributing' part **
If run from a webserver you can store your secure key in a text file, and read this text file into the swf from an assets folder (using urlLoader). People wont be able to get to the assets if you dont set public permissions, and the decompiled swf wont have that value (will just have a variable name).
How is it being distributed?
I would like to have an AIR application available for web download, but have some data customized per-user-download. Think CD-key, or in this case an encryption key and user name, so that the downloaded version can connect to a website and know who it is that downloaded it. As a fail-back if this is not possible, I could require the user to log in once and set one up and then store it locally, though I'd like to make it one-click and seamless. However, if the latter is the only way to do so, what's the best cross-platform-safe way to store local persistent data available to AIR?
Best is subjective. You could use an SQL Lite Database or any sort of local file you prefer. I have distributed XML files with AIR applications before and used them for configuration purposes. I'm not sure if I'd consider an unencrypted XML file secure, but there is no reason you can't encrypt it on disk and decrypt it in memory.
It sounds like you're trying to create a form of licensing scheme. IF so, you can check out third party licensing schemes for AIR applications such as NitroLM, Sharify, Zarquon, or Adobe Shibuya.