2

I found a "lua aes" solution on the web a while ago. And have some concern about its safety.

It states that:

-- Do not use for real encryption, because the password is easily viewable while encrypting.

It says this at its "file encryption test" script.

My questions are:

Why is that, how is it any different from encrypting a string and writing it to a file?

How could it be viewable while encryption? Is it viewable after encryption too?

Basically, Is it safe to use or not?

Is there anyone who can confirm this who has used it? I mailed the original developer but the email address was invalid.

Should I be using it at all?

user1058431
  • 185
  • 1
  • 3
  • 12

2 Answers2

7

I assume there are two reasons why that recommendation was made:

  1. Strings are immutable in Lua, so there is no way to overwrite a string with different data once it's created.
  2. In Lua, objects are garbage collected. The garbage collector runs only at certain points in the program, and the application has no way of telling when the garbage collector will run after there are no more references to the object. Until then, the password string will remain in memory by point 1.

See Java's case, which is similar to Lua:

Why is char[] preferred over String for passwords?

As you can see there, using char arrays instead of strings is a better way to store passwords, since arrays are mutable and can be reinitialized to zero when done.

The closest Lua equivalent to a char array is a table filled with numbers. Here the password is stored as a table, rather than a string, where each element in the table consists of the integer representation of each character. For example, "pass" becomes {0x70,0x61,0x73,0x73}. After the table containing the password is used to encrypt or decrypt, it is filled with zeros before it's unreachable by the program and eventually gets garbage collected.

According to your comment, I may have misunderstood. Maybe the "file encryption test" stores the password in plain text along with the encrypted file, allowing anyone with access to the file, even attackers, the ability to trivially decrypt it. The points above still apply, though. This is still only a guess, however; I can't know exactly what you mean unless you provide a link to the encryption library you mention.

I've taken a look at the AES library and the concern about the password being "easily viewable" occurs because the user types the password in plain text, through the command line or terminal, in order to start the Lua program, even though the output of the program contains only cipher text. A slightly more secure way of providing the password would be not to show the input (as is done in sudo) or to mask the input with dots or stars (as is done in many Web pages).

Either that or the points given above are perhaps the only logical explanation.

Community
  • 1
  • 1
Peter O.
  • 32,158
  • 14
  • 82
  • 96
  • 2
    these two papers: [_Data Lifetime is a Systems Problem_](http://xenon.stanford.edu/~talg/papers/SIGOPS04/abstract.html), and [_Shredding Your Garbage: Reducing Data Lifetime Through Secure Deallocation_](http://www.usenix.org/event/sec05/tech/chow.html) might be interesting to those that want to know more about the problem and how some are attempting to solve it. – Dan D. Jan 29 '12 at 10:54
  • Warning: it might also be that the LUA implementation does not offer side channel protection. E.g. if you use the AES cipher as response to another system, it might be that it leaks information that could be used to reconstruct the key (but as most users forget to add integrity protection, that argument may be mute). – Maarten Bodewes Jan 29 '12 at 15:00
  • Yes I see how that can be a problem. But the way you describe it, the entire thing is unsafe/insecure. It only stated that quote when "file encryption". Also I guess it wouldn't matter what encryption solution I would use, the problem remains the same. But how can it be overcome? – user1058431 Jan 29 '12 at 17:40
  • @user1058431 You should provide a link to the encryption library so I can see what your concern is. – Peter O. Jan 29 '12 at 17:52
  • @Peter O., here is the link: http://files.luaforge.net/releases/aeslua/aeslua/0.2. – user1058431 Jan 29 '12 at 18:08
  • @Peter O., Oh ok, than I guess the implementation itself is safe? Btw, is there a way to create a mutable string than perhaps? To overcome the main problem described above in your first post. Thanks for checking it out btw. – user1058431 Jan 29 '12 at 19:03
  • @Peter O., so you mean like t = {"p", "a", "s", "s"} or t = ["pass"]. And than later just t[1]=0 etc etc ? – user1058431 Jan 29 '12 at 19:10
  • @Peter O., nice. To reach "0x70" you have to add the "0x" manually right? Actually to be sure, how did you reach {0x70}. From string.byte to format.hex right? And it will automatically be deleted, because how or where or what will fill it with zeros before it goes out of scope? – user1058431 Jan 29 '12 at 19:28
  • @user1058431: The `0x` indicates a hexadecimal number, in this case `p` means `0x70` in the character set. (`0x70`, here, is a number, not a string, hence the lack of quotation marks.) The table containing the password is filled with zeros right after the encryption routine finishes encrypting the data (or even sooner, since the password is, in reality, converted to a key), to prevent the password from remaining in memory after it goes out of scope. The table will automatically, but not necessarily immediately, be deleted by the garbage collector after it goes out of scope. – Peter O. Jan 29 '12 at 19:40
  • @Peter O., ok, but how would I convert "p" into a hexadecimal number? I did reach "70" but by using the string library. If I were to only decrypt it, I could say make a table with {0x70,0x61,etc} beforehand, but if I were to convert a given password via for example user input how could I make sure its safe by creating/converting to those hexadecimal numbers? – user1058431 Jan 29 '12 at 19:55
  • It's getting a little off topic for me to detail exactly how to convert the password to characters in a way to make it safe. My answer pretty much contains enough information to answer the current question as given. If you want more details, you should ask a separate question and possibly accept this answer by clicking the checkmark. – Peter O. Jan 29 '12 at 20:02
  • I made a new topic here: http://stackoverflow.com/questions/9056323/convert-password-to-hexadecimals. – user1058431 Jan 29 '12 at 20:10
  • To get back on your question about side channel attacks: it is up to the library to make sure it is not vulnerable to side channel attacks. It is a probably less important when encrypting files (as there may be nobody who could launch such an attack). But even then there have been studies where RSA private keys have been retrieved by running another application on the same chip core. Note that their implementation runs at truly abysmal speed, and maybe more vulnerable for that reason alone (400 Kbit/s is not something I would consider fast for AES). – Maarten Bodewes Jan 30 '12 at 10:32
1

You may also try out alternate methods, like LuaCrypto, which is a binding to OpenSSL and is able to encrypt data using the AES standard.

Michal Kottman
  • 16,375
  • 3
  • 47
  • 62
  • This seems to be a much better tested and useful method of performing AES. It's security and speed will be a factor 1000 better than the LUA only option, for starters. – Maarten Bodewes Jan 30 '12 at 10:33
  • 1
    Can someone please give an example of how to use this library? The examples given are very small and trivial and doesn't help new people trying Lua. I downloaded the project from git, managed to do ./configure;make;make install but when trying require("crypto") in lua shell, I get the following error. > require("crypto") stdin:1: module 'crypto' not found: no field package.preload['crypto'] no file '/usr/local/share/lua/5.3/crypto.lua' ... – Amudhan Feb 25 '19 at 13:49