Re: encrypt/decrypt functions for a session
On Dec 5, 2007 1:21 AM, thomas wrote: Thank you, Ben! That's exactly what I meant. For this, keeping a variable in a script-local function would suffice -- I personally haven't found a way yet to access a s:var. ... Also, you will most likely have to define functions that decrypt the stuff. So, if bad people really gained access to your terminal, nothing would stop them from calling these functions (calling script-local functions isn't difficult). This could be less safe than keeping them plain text in a script-local variable (which I don't know how to access from within an unpatched vim). /me nods emphatically. That's what I was trying to express but couldn't seem to find the words for. It doesn't protect you against a determined hacker, or against inspection of your core files, but just using plaintext in a s: var protects you from curious co-worker attacks. BTW maybe I missed something but if you store passwords in a script local variable how could they show up in session files? In fact, s: variables don't seem to be saved in session files, either (correct me if I'm wrong, but that's what a quick test, as well as a glance at the help, seemed to show). Against which kind of attacks would you like to protect the passwords? #1 echo :echo g:my_passwords #2 session :exec 'edit '. v:this_session #3 core dump inspection? #4 ... Does anyone know of a way to display an s:var from inside vim? If not, using plaintext in an s:var protects you from #1 and #2, and there is no way to protect against #3: Someone with access to your core file can access the encryption key (even if it's vim's start time, vim has to be storing that somewhere to give it to you) and the encrypted text, as well as vim's decrypt function. What would encryption give us that s: vars don't? ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
and there is no way to protect against #3: Someone with access to your core file can access the encryption key (even if it's vim's start time, vim has to be storing that somewhere to give it to you) Not necessarily. If it can be got by a system call when it is needed and then popped off the stack after use. Unless Vim dumps core while it is decrypting the pw, but in that case it's also likely the pw is stored in plaintext somewhere as well. But, yes, that said, protecting against someone with access to core files is next to impossible. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
On Dec 3, 2007 4:59 PM, Charles E. Campbell, Jr. wrote: Matt Wozniski wrote: On Dec 3, 2007 2:05 PM, Charles E. Campbell, Jr. wrote: Assuming that I have an encrypt/decrypt function pair, the pid could be used as a single-session p/w that would be transparent to the user. I don't see any point in saving a ftp password but requiring the user to enter some other password to make the ftp password available. Such things as recording the hundredth of a second that vim/gvim started along with the pid would act as an improved session-only password. Sure, I understand that you could use it as a key to encrypt the password, but what I'm really asking is what you gain from that. Is it really more secure to have an encrypted string and its decryption key stored in memory than it is to have an unencrypted string in memory? Particularly on an open-source project where anyone who wants to can view your source code? Where's the part where I said I'd store the session pid in some variable? Something like getpid() would be called during encrypt/decrypt, not stored. My point was that a would-be cracker would have access to both the encryption key and the encrypted text. Using the pid as the key is not made more secure by not storing it, since that cracker would also have access to the hypothetical getpid() function; it just saves him the trouble of accessing a variable to get the key. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
My point was that a would-be cracker would have access to both the encryption key and the encrypted text. Using the pid as the key is not made more secure by not storing it, since that cracker would also have access to the hypothetical getpid() function; it just saves him the trouble of accessing a variable to get the key. ~Matt I'm not sure the point is really to stop a cracker. If someone has access to your terminal with your user privileges and the password is stored, encrypted or not, they can get at it, unless decrypting it requires typing a password which defeats the point, of course. Rather, I would think the value in this is more so that if you're working with somebody else observing and for some reason issue :let or such, your password doesn't magically appear on the screen in plaintext for all to see. Passwords usually don't appear on the screen in plaintext as you're typing them, and they shouldn't be easy to accidentally bring up in plaintext for anyone who happens to be watching to see. To solve the problem, the encryption needn't be strong--it just needs to be good enough that casual inspection wouldn't reveal it, i.e. not just rot13. Likewise, a plaintext password shouldn't be stored in a session file--better to store some garbage that can't be decrypted next time, and require the user to retype the password once per session. So, far from being an attempt to stop a cracker who has access to your session, which is a hard kind of cracker to stop, it's more an attempt to stop accidental discovery of your password, or to stop yourself accidentally revealing it (e.g. by saving a session--who'd have thought that could reveal your password?). That's my take on it, anyway. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
Thank you, Ben! That's exactly what I meant. For this, keeping a variable in a script-local function would suffice -- I personally haven't found a way yet to access a s:var. (If you know of a vim-only solution, please tell me.) Although rot13 is of course is no encryption/obfuscation at all, IMHO a randomized replacement table method probably won't be any less secure than saving the passwords to disk (ready for take-away and later inspection). Also, you will most likely have to define functions that decrypt the stuff. So, if bad people really gained access to your terminal, nothing would stop them from calling these functions (calling script-local functions isn't difficult). This could be less safe than keeping them plain text in a script-local variable (which I don't know how to access from within an unpatched vim). BTW maybe I missed something but if you store passwords in a script local variable how could they show up in session files? Against which kind of attacks would you like to protect the passwords? #1 echo :echo g:my_passwords #2 session :exec 'edit '. v:this_session #3 core dump inspection? #4 ... thomas. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
On 02/12/2007, Yakov Lerner [EMAIL PROTECTED] wrote: Maybe a patch to add getpid() function to vimscript is not bad idea ? Even without relation to Charles ciphering troubles. I second Yakov's idea. -- Registered Linux User #445632 http://counter.li.org --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
On 03/12/2007, Matt Wozniski [EMAIL PROTECTED] wrote: 3. This entire discussion seems to basically be a moot point since any cracker worth his salt would just be sniffing the network... FTP transmits passwords in plaintext; security in how netrw handles the passwords seems to be a rather moot point to me. netrw doesn't only handle FTP transfers. Better types of traffic are supported. I just don't like the idea that my password is sitting in a global vim variable for all to see. If I walk away from my keyboard, someone could walk by and type :echo netrw_passwd Plus, if/when I dump core, my password is there, in cleartext, in the dumpfile. Again, something I don't want to leave to filesystem perms to protect me from. Especially if I happen to be using an OS that FTPs dumpfiles back to the mothership for you. Erik -- Registered Linux User #445632 http://counter.li.org --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
since the cracker will only need to get two values from vim's memory instead of one. Am I missing something? This assumes an attack that is specifically targeted at an individual vim user using a specific version of the netrw plugin. This isn't the most likely scenario though. (Depending on your workplace maybe.) --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
Matt Wozniski wrote: Fixing that to use a script-local variable would definitely be a worthwhile change that should be made ASAP, though it still wouldn't protect you from plaintext passwords being in your core files. Yes, I've done that for v116g. While we're at it, what is a reasonable use-case for why someone would need a getpid() function? Why would we need to know our PID? Assuming that I have an encrypt/decrypt function pair, the pid could be used as a single-session p/w that would be transparent to the user. I don't see any point in saving a ftp password but requiring the user to enter some other password to make the ftp password available. Such things as recording the hundredth of a second that vim/gvim started along with the pid would act as an improved session-only password. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
On Dec 3, 2007 2:05 PM, Charles E. Campbell, Jr. wrote: Matt Wozniski wrote: Fixing that to use a script-local variable would definitely be a worthwhile change that should be made ASAP, though it still wouldn't protect you from plaintext passwords being in your core files. Yes, I've done that for v116g. Glad to hear it. :) While we're at it, what is a reasonable use-case for why someone would need a getpid() function? Why would we need to know our PID? Assuming that I have an encrypt/decrypt function pair, the pid could be used as a single-session p/w that would be transparent to the user. I don't see any point in saving a ftp password but requiring the user to enter some other password to make the ftp password available. Such things as recording the hundredth of a second that vim/gvim started along with the pid would act as an improved session-only password. Sure, I understand that you could use it as a key to encrypt the password, but what I'm really asking is what you gain from that. Is it really more secure to have an encrypted string and its decryption key stored in memory than it is to have an unencrypted string in memory? Particularly on an open-source project where anyone who wants to can view your source code? ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
Matt Wozniski wrote: On Dec 3, 2007 2:05 PM, Charles E. Campbell, Jr. wrote: Assuming that I have an encrypt/decrypt function pair, the pid could be used as a single-session p/w that would be transparent to the user. I don't see any point in saving a ftp password but requiring the user to enter some other password to make the ftp password available. Such things as recording the hundredth of a second that vim/gvim started along with the pid would act as an improved session-only password. Sure, I understand that you could use it as a key to encrypt the password, but what I'm really asking is what you gain from that. Is it really more secure to have an encrypted string and its decryption key stored in memory than it is to have an unencrypted string in memory? Particularly on an open-source project where anyone who wants to can view your source code? Where's the part where I said I'd store the session pid in some variable? Something like getpid() would be called during encrypt/decrypt, not stored. Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
That's good unless your /proc/sys/kernel/core_pattern contains %p, or /proc/sys/kernel/core_uses_pid == 1 On 03/12/2007, Charles E. Campbell, Jr. [EMAIL PROTECTED] wrote: Matt Wozniski wrote: On Dec 3, 2007 2:05 PM, Charles E. Campbell, Jr. wrote: Assuming that I have an encrypt/decrypt function pair, the pid could be used as a single-session p/w that would be transparent to the user. I don't see any point in saving a ftp password but requiring the user to enter some other password to make the ftp password available. Such things as recording the hundredth of a second that vim/gvim started along with the pid would act as an improved session-only password. Sure, I understand that you could use it as a key to encrypt the password, but what I'm really asking is what you gain from that. Is it really more secure to have an encrypted string and its decryption key stored in memory than it is to have an unencrypted string in memory? Particularly on an open-source project where anyone who wants to can view your source code? Where's the part where I said I'd store the session pid in some variable? Something like getpid() would be called during encrypt/decrypt, not stored. Chip Campbell -- Registered Linux User #445632 http://counter.li.org --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
Charles E. Campbell, Jr. wrote: Matt Wozniski wrote: Fixing that to use a script-local variable would definitely be a worthwhile change that should be made ASAP, though it still wouldn't protect you from plaintext passwords being in your core files. Yes, I've done that for v116g. While we're at it, what is a reasonable use-case for why someone would need a getpid() function? Why would we need to know our PID? Assuming that I have an encrypt/decrypt function pair, the pid could be used as a single-session p/w that would be transparent to the user. I don't see any point in saving a ftp password but requiring the user to enter some other password to make the ftp password available. Such things as recording the hundredth of a second that vim/gvim started along with the pid would act as an improved session-only password. Regards, Chip Campbell The sequence :mks! :qa gvim -S would invalidate the password (since the PID changes). I suppose this is what you want? Similarly Gnome-enabled versions over closedown/restart of the Gnome or KDE winmanager. Best regards, Tony. -- Get GUMMed --- -- The Gurus of Unix Meeting of Minds (GUMM) takes place Wednesday, April 1, 2076 (check THAT in your perpetual calendar program), 14 feet above the ground directly in front of the Milpitas Gumps. Members will grep each other by the hand (after intro), yacc a lot, smoke filtered chroots in pipes, chown with forks, use the wc (unless uuclean), fseek nice zombie processes, strip, and sleep, but not, we hope, od. Three days will be devoted to discussion of the ramifications of whodo. Two seconds have been allotted for a complete rundown of all the user- friendly features of Unix. Seminars include Everything You Know is Wrong, led by Tom Kempson, Batman or Cat:man? led by Richie Dennis cc C? Si! Si! led by Kerwin Bernighan, and Document Unix, Are You Kidding? led by Jan Yeats. No Reader Service No. is necessary because all GUGUs (Gurus of Unix Group of Users) already know everything we could tell them. -- Dr. Dobb's Journal, June '84 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
Charles E Campbell wrote: Any good way to get the vim process's pid? How about under Windows? Maybe a patch to add getpid() function to vimscript is not bad idea ? Even without relation to Charles ciphering troubles. Can this be added to the todo ? Yakov --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
On Nov 29, 2007 12:23 AM, Charles E Campbell Jr [EMAIL PROTECTED] wrote: Hello! I don't see any way to encrypt/decrypt strings in the vim function library, but there is a way to encrypt a file buffer. Netrw tries to make use of ftp, etc and its associated passwords simpler by retaining the password in a variable (which is not normally saved). Thus one reads a file via ftp, say, provides the password to do so, and writing is done without requiring another entry of the password. I thought about making a temporary password automatically using localtime() at first invocation of netrw and the process's pid. Any good way to get the vim process's pid? How about under Windows? On unixes that have /proc, you can get pid of vim examining /proc/self. On another note, if all you need is some pseudorandom number, you can try extract all digits from tempname(). Supposed to be relatively unique. In my linux, :echo libcallnr(libc.so.6, getpid, ) prints pid of vim. Surprisingly, libcallnr(libc.so, getpid, ) doesn't. On some older linux, that would be libc.so.5 etc. Doing small loop for N and checking existance of /usr/lib/libc.so.N might help. On some other unixes, libcallnr(libc.so, getpid, ) would actually work; to make it work for may unixes, you could trap the error and resort /usr/lib/libc.so.N. On windows, somebody should know name of the library and name of the function for correct libcallnr() call. However, if you need several unique/random bytes, the best way on unix is to read /dev/urandom if it exists. Yakov --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
thomas wrote: However, I suspect that there's no way to get vim to feed the p-r-b-password to the builtin encryption/decryption facilities. I thought the :X command does little more than setting the key option? At least from running some (i.e. two) tests, I'd say that you could also encrypt a file by setting the key option to a password (setlocal key=foo) before saving. IIRC the encryption is rather weak though (with vim 7.1). Not much I can do about the encryption method, but perhaps its better than plaintext. And, the expected use of the process ID is amenable to searching, anyway. I'm now feeling that the procedure is more likely to work: * ask user for password * place password in its own buffer * specify encryption for the buffer with set key=... using process pid * save the buffer When the user wants to read/write using that password transparently in the future * check if buffer exists * use the process id and set key on a new buffer, read password-containing buffer * use decrypted password to do file transfer I'm not at sure that this complicated process is worth the trouble, though: * the search is limited to potential process IDs, so that's a rather limited search space * a buffer or two is created with the password in the clear, and a file is saved with that (encrypted) password. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
Tony Mechelynck wrote: Yakov Lerner wrote: On Nov 29, 2007 12:23 AM, Charles E Campbell Jr [EMAIL PROTECTED] wrote: Hello! I don't see any way to encrypt/decrypt strings in the vim function library, but there is a way to encrypt a file buffer. Netrw tries to make use of ftp, etc and its associated passwords simpler by retaining the password in a variable (which is not normally saved). Thus one reads a file via ftp, say, provides the password to do so, and writing is done without requiring another entry of the password. I thought about making a temporary password automatically using localtime() at first invocation of netrw and the process's pid. Any good way to get the vim process's pid? How about under Windows? On unixes that have /proc, you can get pid of vim examining /proc/self. [...] ...which is a soft link to /proc/ where is your PID. But the difficulty is to do it without starting a different process such as bash, ls, etc. (the subprocess would return its own PID, not yours). However, since Dr. Chip is the author of the netrw plugin, maybe he can find a way to do it. But on Windows it wouldn't work. The pseudo-random number is one thing; the main problem is the lack of functions to encrypt/decrypt an arbitrary string. I suppose I could try to take the pseudo-random-based password, use :X, and save it to a file, and then read that file back in to retrieve the password. However, I suspect that there's no way to get vim to feed the p-r-b-password to the builtin encryption/decryption facilities. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
