I'm trying to use PoDoFo (0.9.2) to decrypt (and later encrypt) files. However, the code does not support AESV2 which is currently the de-facto standard. I didn't find any material about this issue and I was wondering if anyone tried to tackle it or to patch the library to make it usable.
Related
I am using AES-GCM from crypto-js presently. The intent would be to change to RSA for the asymmetric cryptography. Is the following statement correct https://community.postman.com/t/http-message-signing-using-rsa-sha256/1791
?
However, CryptoJS doesn’t support RSA, and it’s the only crypto
library available in the Postman Sandbox. So I’m sort of stuck, unless
I implement a RSA-SHA256 signing algorithm myself.
Now, I’ve noticed that crypto-js hasn’t had a single commit for a year
on GitHub,
I would really prefer to stick with the crypto-js library since it was difficult to use the built-in SubtleCrypto and now we have a framework built around the crypto-js libraries. That would basically have to be scrapped to go to SubtleCrypto. Pointers appreciated.
As #Topaco mentions the crypto-js is a symmetric encryption library only. I did pivot to tweet-nacl and it is working well.
I have a problem when attempting to implement AES/RSA encryption on J2ME,
that problem being that bouncycastle (a library that supports java and specially J2ME) is too big for implementation on a mobile phone solution (about 860 classes in total without the test and example classes).
I've googled around and the only alternative I can really find is JCE... which in itself is also too big.
Does anyone here know a way to implement it in a very small solution? Or a "tiny" library that I can use? (like for instance for TEA: http://www.winterwell.com/software/TEA.php)
If you are willing to do a little work you should be able to take the Bouncycastle J2ME source code as a starting point and with judicious use of copy and paste implement just RSA and AES very compactly.
UPDATE:
Just as an exercise I tried this myself. It took about 45 minutes of copying and light editing to produce 27 Bouncycastle classes that completely implemented AESEngine and RSAEngine exactly as they are in Bouncycastle J2ME sources. But I did no testing of them at all, namely because I don't really understand what to do with my Netbeans J2ME project that I created them in.
How about you try the lightweight API version? Go to Bouncy Castle's latest release page and download the J2ME build. Its just about 7MB - much lighter in size.
I need to use AES encryption in my embedded Erlang application, but OpenSSL is unavailable for my target system and so the crypto library from OTP can't be built. I probably could cross-compile OpenSSL as well, but I would prefer a pure Erlang solution to remove another dependency. Does one exist?
Looked at this a while ago and found no nice solution other than OpenSSL/crypto. Sorry.
Unless someone made a new library recently but I haven't heard about it since then.
It's more likely that someone has already solved the problem of easily installing OpenSSL on your target system. Would focus my energy on that instead.
The crypto module has been OpenSSL dependent for a long time. The pure Erlang version might not be impossible, but it will be very very slow and will not be practical in use.
We need a paid for supported Encryption / Decryption API for a project - AES >256?
I dont want the developers coding their own encryption / decryption even using the built in stuff. To many chances to go wrong.
Links to sites much valued.
UPDATE
Due to the fact as many have said - Its hard to understand if you are not familar with encryption, and get a small thing wrong and its busted...
I have seen answers and will be getting our own encryption/decryption from the builtin - but all the team will need to peer review.
For information BlowFish.Net is good, and performs faster than the builtin crypto routines, which when you start to look at encrypting/decrpyting data into a database can have some massive perf issues ...
http://www.codinghorror.com/blog/archives/001268.html
"even using the built in stuff"
The reason that it's built in is so that people have tested, reliable algorithms available to use that implement standards, not black box third party APIs that might not. What are the "chances to go wrong"?
Maybe you need to switch to Java, you can always opt to use third party JSSE providers there if you're paranoid about the built-in provider.
Bouncy Castle is a well respected and well developed .NET encryption library that is usually recommend for these sorts of questions. But what's wrong with using the System.Security.Cryptography Namespace? - it is extremely secure, very fast and doesn't require any external libraries. Here's an example of how to implement it.
Oh, and "using the built in stuff" will mean it is less likely to go wrong. Your developers won't be coding their own classes, just using the interfaces available which are easy to use and have been very rigorously tested.. Also, the "built in stuff" will be well supported by Microsoft, so if you want to upgrade to C# 4.0 (or C# 5.0 in the future?) you probably won't need to change your code at all.
If you were to use a 3rd party library you would most likely still run into the same issues, which basically boil down to not understanding the pitfalls of encryption.
Without a decent understanding you'll most probably make mistakes with key management, or using bad initialisation vectors or keys. These are issues you'll need to understand to tackle regardless of whether you use the inbuilt libraries (which are fine), or a 3rd party library.
If its something you feel worried about enough, the best recommendation is probably to bring in someone, or better yet - train up people to understand encryption.
Use the builtin 'stuff'. But make sure you use it in the correct mode.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I've written (most of) an application in Flex and I am concerned with protecting the source code. I fired up a demo of Trillix swf decompiler and opened up the swf file that was installed to my Program Files directory. I saw that all of the actionscript packages I wrote were there. I'm not too concerned with the packages, even though there is a substantial amount of code, because it still seems pretty unusable without the mxml files. I think they are converted to actionscript, or atleast I hope. However, I would still like to explore obfuscation.
Does anyone have any experience with Flash / Actionscript 3 / Flex obfuscators? Can you recommend a good product?
The procedure suggested by maclema will not really stop any attacker from obtaining the source - the "wrapper application" will need to be unencrypted so the attacker will be able to find out that you use AES (or any other algorithm) and he will obtain the decryption key in a similar way (because it needs to be in plaintext somewhere). Once he has this, he will be able to decrypt your SWF file easily.
The only reliable solution (well...) is some kind of obfuscator - we use Amayeta which works for Flex in the latest version - please see http://www.amayeta.com/software/swfencrypt/ .
Here's what I would do.
Compile your application to a SWF file. Then encrypt the SWF using AES.
Make a "wrapper" application that loads the encrypted SWF into a ByteArray using URLLoader
Use the as3crypto library to decrypt the swf at runtime.
Once decrypted, use Loader.loadBytes to load the decrypted swf into the wrapper application.
This will make it a lot harder to get your code. Not impossible, but harder.
For AIR applications you could leave the SWF encrypted when delivering the application to the end-user. Then you could provide a registration key that contains the key used to decrypt the SWF.
Also, here is a link to an AS3 obfuscator. I am not sure how well it works though.
http://www.ambiera.com/irrfuscator/index.html
Well, in my opinion, the easiest and safest solution is a mix of maclema and Borek answer:
Obfuscating code can be a big headach if you did not include it in your process from the start and if your aplplication is quite big: it's likely that obfuscation make your application corrupted if you used remote packages (and did not declare this to the obfuscator) if you used to many unTyped variables in Objects or dynamic classes ....
So: if you do maclema's solution on your big application and use obfuscation on your wrapper (which is a small app likely to be very easy to obfuscate) you're code will be the safest and the hasle the least.
Only a very angry pirate would take the time to reverse engineer the obfuscation to then decrypt the package .... Well if someone wants your application code soo bad it's either CIA related or you're already very rich (or both)
thank you all for your answers
I recently released an iOS and Android game using Flash. I looked around the internet for a good free program to protect the source code in my SWF and couldn't find anything so I wrote one. It's still in development and it's "use at your own risk" but it worked for me.
It's released on github. Check it out and let me know what you think.
https://github.com/Teesquared/flasturbate
I uploaded a windows binary but I recommend you follow the instructions to build it yourself if you want to give it a try.
This obfuscator works directly on the SWF file. It currently only renames symbols but it is built on a framework that could support altering bytecodes in the future.