Jiro's pick this week is cryptAES by Jan Simon.
I do a lot of things in MATLAB, and if I could make it wash my dishes, I would. Perhaps one of these days, I should venture out to the Simulink world to design and implement some controllers for a dish mounting/washing robot. But let's leave that for some other time. The other day, I wanted to create a simple database mechanism to store all of my username and passwords to various online accounts I had. Since this database would contain sensitive information, I needed this to be pretty secure. I knew that I could create a password-protected Excel file, but what fun would that be?
So I built this simple GUI in MATLAB that showed my username/password entries in a table format. I could add, change, or delete entries from the table. But I needed a way to store that data in an encrypted format. I know very little about data encryption but I know that there are sophisticated algorithms for it. I did a quick search on the File Exchange and found Jan's cryptAES. It implemented the 128-bit AES en/decryption. What that translates for me was that I now have a way of garbling my confidential files so that others can't see it! I can take my data from the table and encrypt it as some binary file using a passphrase I provide. When I open the GUI, I would type the passphrase which would load and decrypt the file.
His entry is purely written in MATLAB (without any calls to external functions like Java or MEX). While calling the Java method is significantly faster (see Rapid AES En/Decryption), Jan explained to me a couple of advantages for doing everything in MATLAB:
- He cannot control whether the CBC vector of the Java implementation is really random, because it depends on the active Java engine. He said he's seen too many advanced crypto-softwares failing due to poor random number generators.
- By P-coding the function (and not calling any external functions), it makes it harder for hackers to catch the intermediate state.
He acknowledges two other File Exchange entries - AES Toolbox and Rapid AES En/Decryption. Some of you may be interested in checking them out as well.
Comments
Thanks, Jan, for helping me solve my problem! And thank you for explaining to me a little more of your motivations in creating this entry.
Give this a try and let us know what you think here or leave a comment for Jan.
Get
the MATLAB code
Published with MATLAB® 7.11
Hi Jan,
I am interested in checking out and using your GUI for passwords in association with CryptAES in your most recent posting. Can you let me know if you can make that available?
Thanks.
Comer
Dear Comer,
Jiro has created the GUI, which uses AES encryption to hide informations on the disk. I’ve published the encryption and decryption part only. I’ll hesitate to submit a complete GUI to the FEX: a pure M-file is too easy to corrupt by other users who have write permissions to your files. A P-coded file is not accepted in the FEX – and I would not trust a foreign P-file for keeping confidential passwords.
I’m working on an M-file, which modifies itself before P-coding, but this will take some time.
Kind regards, Jan
Are you still able to “debug” P-code in newer releases? On R2008, you are able to step into P-coded files and look at the internal variables by stepping in from the p-code function call. You can’t see the code, but the debug points jumps from line to line (although blank). It’s easy enough to do whatever you want if you can look at the internal P-code state in the workspace viewer.
@Brian,
It seems like you can still debug a P-coded file in R2010b. I believe our development is aware of this, but let me notify them of this behavior. If you’d like, you can also submit an enhancement request here.
@Brian:
I was surprised that the feature of debugging P-files in the editor window has been implemented at all. In which situation could this be useful, except for inspecting what others tried to hide?!
You can impede the debugging with some tricks:
1. Shaddow DBSTEP (ans the other DB…-functions) by local variables. Then the DBSTEP-Button of the debugger in the editor window is not working any longer.
2. Shaddow DBSTEP by a local function in addition, if a cute user calls “evalin(‘caller’, ‘clear(”dbstep”)’) from any subfunction.
3. The user can call “builtin(‘dbstep’)” from the command line. So shaddow even BUILTIN.
4. Unfortunately you can call “evalin(‘caller’, ‘whos’)”, if you stop the debugger in any called subfunction. So actually calling subfunctions must be avoided, if you want to hide the values in a P-file. E.g. use SWITCH instead of STRCMP to compare strings.
5. The debugger goes through the code “line by line”! So put all commands in a single line before P-coding. But even then EVALIN remains an invitation to curious users as long as external functions are called.
My conclusion is, that only encrypted data are really hidden in P-files.
Kind regards, JAn
Sorry, the function CryptAES is longer available.
TMW has decided to delete it, because it uses more than 64 bit for encryption. This policy is based on the U.S. Export Administration Regulations governed by the U.S. Dept. of Commerce, Bureau of Industry and Security.
Feel free to contact me in case of questions.