I need a simple,small and efficient program for the following thing to do.
A small interface to choose a file from my PC.
Press encrypt/De-crypt button to do select whichever you need.
If encrypt is pressed, generate a random key and encrypt with some algorithm based on that key.
If decrypt is pressed decrypt the file using some algorithm.
I am planning to do it in visual C++. Can anyone please suggest a small program in VC++ to do this? or please tell me the library name where I can get all the functions to do the above.
If you think that there is some better language or framework available to do instead of VC++, please suggest. Thanks. I would very much grateful to you for this help.
Visually C++ can call clr code when compiled with these options. Once you have done that, you can use this api or the far more secure version that Microsoft published here. I'd use the second because then you get authenticated encryption for free. Otherwise you need to hmac the data and check it on the other end, which is a pain. In either case, make sure you use a random IV each time ( by default when you instantiate aes in .net , it creates a random IV so just use that). Prepend it to the message and retrieve it when you decrypt
Related
During API automation, I do have a requirement to encrypt the password and decrypt runtime just before using it in Karate.
Is there any specific inbuilt method available to do so?
If it is not available, can anyone please guide me on how to do this?
There's nothing built into Karate because you can easily plug in anything via Java interop: https://github.com/intuit/karate#http-basic-authentication-example
You can find plenty of Java code examples that will do what you want.
Right now im storing passwords in plain text in the registry, i'd prefer not to use plugins, but does NSIS have any built in methods to actually encrypting plain text into the registry?
Thanks
Most string things can be done with the basic building-blocks; StrCpy, StrCmp andStrLen. For encryption/decryption you might need Asc and IntFmt $foo "%c" $bar as well.
You probably have to code the implementation yourself by inventing a new algorithm (Never invent crypto unless you know what you are doing) or using some existing scheme ported to NSIS. To me this seems like too much work just to avoid using a plugin.
A much better option IMHO would be to call the protected storage API with the system plugin...
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.
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 intend to develop a J2ME application, that should be able to read words from the English Dictionary. How do I interface to/and store a Dictionary ? Will I have to create the Dictionary myself, by inserting words, or is there a third party Dictionary available with APIs?
There are several online dictionaries available, but if you want a quick, simple solution and you're running on a *NIX server, then try looking at /usr/share/dict/words, which will be on most servers. It's a list of English words, one per line.
There are definitely free dictionary files, so you don't need to make one yourself!
A good starting point is looking at a Java SE implementation of a spell checker, such as Jazzy on Sourceforge. It has dictionary files included in the project, and by inspecting the code you can get an idea of how to integrate it into your own J2ME app.
Your major challenge will be to be able to search the dictionary in an efficient manner using J2ME since it can be slow in comparison to its desktop coutnerpart.
Try the word-lists detailed in Kevin's Word List; it contains links to many different English language word-lists and related resources.
You can download an appropriate one from the site and use it directly, no need for an API as the content should nominally be just plain-text which you can load into the program or store in a database to allow for fast lookups.
Just download the dictonary created by OpenOffice, it's for free.