Re: BOF Vim 8 - EncryptLine
Matthew Winn wrote: Text editors don't do encryption and never should. How else would you ensure that you can have encrypted text _without_ the need to temporarily store a plaintext copy of the file? Pipe the text through to an external encryption tool, such as pgp. Assuming your o/s supports true pipes... Chip
Re: BOF Vim 8 - EncryptLine
Robert Lee wrote: What is wrong with SCP/SFTP? If these are not available, externally encrypt the file. You can even make a vim macro to do the job IIRC. Text editors don't do encryption and never should. I promise to stop posting when everyone else does! SCP etc just encrypts the traffic when copying a sensitive file to another machine. After backups are taken and stored, and various other stuff happens, your sensitive file can end up in quite a lot of places. Defence-in-depth means you have to encrypt the actual secret (the file, or the secret parts of the file). As Tony pointed out, Vim can encrypt a file. That is good because if you rely on scripts and what-have-you, there can be temp files, and files left over when something crashes. It's much better if Vim handles the decryption and encryption for you - much more convenient, and reliable, and a lot more secure. I can see that my EncryptLine proposal doesn't have any support. Fair enough - I accept the judgement. But the idea is not stupid. When you document tricky stuff on a network, you end up with a file where normal file-access security is good enough to protect 95% of the content. What about the passwords in the document? You really need to encrypt the file to protect them, but that means you have to decrypt the file (enter its key) everytime you need to extract some fact (like an IP address). I have actually implemented my EncryptLine on an obsolete editor and it works really well - but only because I have a need for it. John
Re: BOF Vim 8 - EncryptLine
On Thu, Jan 18, 2007 at 02:15:36PM +1100, John Beckett wrote: Suggested new feature: Make an easy way to encrypt a secret within a line. Then you can have a simple text file to document stuff, with embedded secrets. On reading, you only need to enter a key if you want to see a secret. I don't think this should be a general vim feature either. Yet another idea to solve this: Why not use syntax and set forgground/background color to the same value to hide the text? Then you don't even notice that there is text. eg hidden Password:$ - end of line revealed Password: my secret pwd $ - end of line you can use regexp to match secrets this way. Marc
Re: BOF Vim 8 - EncryptLine
Marc Weber wrote: Make an easy way to encrypt a secret within a line. Then you can have a simple text file to document stuff, with embedded secrets. On reading, you only need to enter a key if you want to see a secret. I don't think this should be a general vim feature either. Yet another idea to solve this: Why not use syntax and set forgground/background color to the same value to hide the text? Then you don't even notice that there is text. OK - I'm convinced that EncryptLine is not wanted! However, I want the secret to really be encrypted because I use a system to copy my data files from machine to machine for backups. The encryption is to protect the secret if someone somehow gets access to the file. John
Re: BOF Vim 8 - EncryptLine
John Beckett wrote: Marc Weber wrote: Make an easy way to encrypt a secret within a line. Then you can have a simple text file to document stuff, with embedded secrets. On reading, you only need to enter a key if you want to see a secret. I don't think this should be a general vim feature either. Yet another idea to solve this: Why not use syntax and set forgground/background color to the same value to hide the text? Then you don't even notice that there is text. OK - I'm convinced that EncryptLine is not wanted! However, I want the secret to really be encrypted because I use a system to copy my data files from machine to machine for backups. The encryption is to protect the secret if someone somehow gets access to the file. John What is wrong with SCP/SFTP? If these are not available, externally encrypt the file. You can even make a vim macro to do the job IIRC. Text editors don't do encryption and never should. -Robert
Re: BOF Vim 8 - EncryptLine
Nikolai Weibull wrote: Make an easy way to encrypt a secret within a line. [Really complex scheme to implement this.] Why is it not enough to simply implement a function that encrypts/decrypts a range of text, much like g? ROT13s a range of text? Because the scheme needs to be simple to use. Once you have that, you have the danger that you will accidentally encrypt or decrypt twice ... then you can lose data. You need some safety checks from a carefully-written program ... although I suppose you could incorporate all that in your hypothetical function. John
Re: BOF Vim 8 - EncryptLine
Bram Moolenaar wwrote: Suggested new feature: Make an easy way to encrypt a secret within a line. This is very a specific feature. You should implement this in a script, this doesn't sound like something Vim should support internally. OK. I just thought I would mention the concept because I find it useful, and AFAIK it's a novel idea that might have appealed. John
Re: BOF Vim 8 - EncryptLine
Nikolai Weibull wrote: 2. Don't write down passwords at all - use phrases that you remember instead 3. Don't write down passwords where other people might walk by and see what you're typing Let's not start a religious war, but FWIW many authorities have changed their mind and no longer advocate the don't write down a password advice. In particular, any network admin simply has to record passwords and other sensitive information - you can't reliably remember more than two or three passwords, particularly when you're not using them often. There are many password safe utilities for this, but I like a simple text file with the secrets encrypted, yet easily viewable (without changing the file). John
Re: BOF Vim 8 - EncryptLine
On 1/19/07, John Beckett [EMAIL PROTECTED] wrote: Nikolai Weibull wrote: 2. Don't write down passwords at all - use phrases that you remember instead 3. Don't write down passwords where other people might walk by and see what you're typing Let's not start a religious war, but FWIW many authorities have changed their mind and no longer advocate the don't write down a password advice. In particular, any network admin simply has to record passwords and other sensitive information - you can't reliably remember more than two or three passwords, particularly when you're not using them often. I don't understand what you're trying to say in the first part of your sentence. For the second part, see below. There are many password safe utilities for this, but I like a simple text file with the secrets encrypted, yet easily viewable (without changing the file). Which defeats the whole point of having multiple passwords, as if someone figures out the master password then the other passwords will also be available. So it's better to use one good password/passphrase and stick with it. nikolai
Re: BOF Vim 8 - EncryptLine
On 1/19/07, Nikolai Weibull [EMAIL PROTECTED] wrote: Which defeats the whole point of having multiple passwords, as if someone figures out the master password then the other passwords will also be available. So it's better to use one good password/passphrase and stick with it. No, is not. Think in this if someone take one of you email password it only gonna have it not all you passwords. And if someone gonna try to take you password it will try are the password is used and gonna search for it not to the pass to open the file that have the pass. Yes, someone can do it, but this no defeat the whole point if having multiple passwords. -- «Dans la vie, rien n'est à craindre, tout est à comprendre» Marie Sklodowska Curie.
Re: BOF Vim 8 - EncryptLine
On Thu, 18 Jan 2007 11:04:00 +0100, Nicolas Weber
[EMAIL PROTECTED] wrote:
You are correct, I was thinking of this the other way around. My
suggestion would only be security in the sense that someone
reading over your shoulder would be prevented from seeing sensitive
content in the file (e.g. passwords) and would really only be an
extension to folding. No change would be made to the file on disk
(e.g. the file would need to be secured on disk using some other
external mechanism).
this can already been done with g?$ (or g?a{ )...so if you only want
to protect your data from people looking over your shoulders, that's
already there.
Gung'f ab tbbq. Erny areqf pna ernq ebg13 grkg jvgubhg hfvat fbsgjner.
--
Matthew Winn
RE: BOF Vim 8 - EncryptLine
From: [EMAIL PROTECTED] On 1/19/07, Matthew Winn [EMAIL PROTECTED] wrote: Gung'f ab tbbq. Erny areqf pna ernq ebg13 grkg jvgubhg hfvat fbsgjner. Hm. I don't understand. Is that some sort of encryption you're using? Garbled, typo somewhere or spellchecker goofed! :-) ---Zdenek smime.p7s Description: S/MIME cryptographic signature
Re: BOF Vim 8 - EncryptLine
Nikolai Weibull wrote: In particular, any network admin simply has to record passwords and other sensitive information - you can't reliably remember more than two or three passwords, particularly when you're not using them often. I don't understand what you're trying to say in the first part of your sentence. I promise the list that I won't post about this again, but FWIW I'm not telling you how I work, I'm describing how most people in the business say they work (from talking to people, and following lists etc). Most networks have lots of devices which require accounts. A router, a firewall, a mail server, ten other servers, etc. Then there are your various email accounts - some important, some junk. Single sign-on can integrate many, or even most of these. But not all. So, most network admins need to record all the account details, possibly with notes, e.g. just how do you log on to that wireless access point that you last configured six months ago. There are many password safe utilities for this, but I like a simple text file with the secrets encrypted, yet easily viewable (without changing the file). Which defeats the whole point of having multiple passwords, as if someone figures out the master password then the other passwords will also be available. Given that you're going to reveal the password to anyone with a knife, there doesn't seem to be much point in having bullet proof security. I'm sure many people do as you suggest, but take it from me that many other people do not use the same password on their firewall and their mail server etc. So it's better to use one good password/passphrase and stick with it. Diceware is a really nice system: http://www.diceware.com/ John
Re: BOF Vim 8 - EncryptLine
John Beckett wrote:
Suggested new feature:
Make an easy way to encrypt a secret within a line.
Then you can have a simple text file to document stuff, with
embedded secrets. On reading, you only need to enter a key if you
want to see a secret.
Example lines before encryption:
server12 { admin topsecret } any text
mybank { account 123456789 pin 1234 }
Example lines after encryption:
server12 {~8vP09fb3+Pn6+/z9/v8AAwocSE9cDYPAYJUThgE} any text
mybank {~afSDKoy9saGMCZ91x6F7pHkwdzEcMBoGCSqGSIb3DQEJ}
When viewing a file with encrypted secrets, it doesn't matter if
others are shoulder surfing. You only need to get rid of onlookers
for the short time it would take to enter a key and view a secret in
the message line (which would not change the file).
I can remember using a mail client that had a feature much like that,
except that blocks of encrypted text in the message were introduced by
a line saying [encrypt]. I forget how they were terminated. I think
it's important to have a more distinctive marker than { and } because
otherwise people will be inadvertently encrypting sections of their C
programs.
[snip]
DecryptLine reverses EncryptLine, changing the current line. It does
nothing (apart from display an error) if the result is not
reasonable (the ciphertext must be a tilde followed by base64, and
the decryption should satisfy certain sanity checks, and should
yield printable text starting with a space). This is a safety check
to avoid losing data if the wrong key is used to decrypt.
Perhaps a safer way is to have a hash as part of the encrypted text.
When the text is decrypted the result is checked against the hash as a
confirmation of validity. Merely detecting printable text is hard
when most characters are printable.
On Thu, 18 Jan 2007 00:21:57 -0600, Robert Lee
[EMAIL PROTECTED] wrote:
Since this requires the file to contain markup characters on the line,
its usefulness is limited in source files where the tags { and } would
cause a syntax error and cannot be marked as comments.
I can't think of any reason why this would be useful in source code.
The point of encryption is to protect data, so the data must be
encrypted in the file and revealed on the display (the way Vim already
does it for entire files). Source code must be stored on disk in
unencrypted form or otherwise it can't be used.
You seem to be thinking of this as a way of storing cleartext in the
file but hiding it on the display, which is essentially no security at
all.
As long as this
limitation is acceptable, I think it might me equally as useful and
perhaps more simple and intuitive if instead foldmarkers were used
along with the fold commands (zc, zo):
Password fold exposed:
?php
$admin_password = /*{{{*/ 'maryhadababyitsaboy' /*}}}*/ ;
?
Password fold closed:
?php
+-- 1 line: $admin_password = * ;
?
This has some advantages:
[snip]
- Count of *'s is indicative of length of hidden area (user can add
whitespace padding to obscure when desired)
That's a really bad idea. Anyone who shouldn't know what's there has
absolutely no business knowing how long the obscured text is, and
even those who know the password shouldn't need to care. If you're
performing an assignment like $password = some string you don't
really care what the content of the string happens to be, but only
that it's assigned to a variable.
--
Matthew Winn
Re: BOF Vim 8 - EncryptLine
Nicolas Weber wrote:
Hi,
You are correct, I was thinking of this the other way around. My
suggestion would only be security in the sense that someone reading
over your shoulder would be prevented from seeing sensitive content
in the file (e.g. passwords) and would really only be an extension to
folding. No change would be made to the file on disk (e.g. the file
would need to be secured on disk using some other external mechanism).
this can already been done with g?$ (or g?a{ )...so if you only want
to protect your data from people looking over your shoulders, that's
already there.
Nico
Nicolas,
Thanks for the feedback, I wasn't even aware of this feature. My only
concern here is that it appears to change the buffer contents (not just
the view). A subsequent w will write this change to disk -- a possibly
undesired result. Also, executing such a command on a password while
someone is watching only brings attention to the password, which appears
in clear text until the command sequence has been completed (where-as
folding can be applied automatically when the file is opened, and each
fold remains closed until explicitly opened).
This is such a rare scenario, however, that I think I'm over-analyzing
it. Vim works great for me exactly as it is. :o)
-Robert
Re: BOF Vim 8 - EncryptLine
On 1/18/07, Robert Lee [EMAIL PROTECTED] wrote: Also, executing such a command on a password while someone is watching only brings attention to the password, which appears in clear text until the command sequence has been completed (where-as folding can be applied automatically when the file is opened, and each fold remains closed until explicitly opened). Seriously, where the hell are you sitting writing down passwords where people walk by you and drop down over your shoulder to sneak a peek? A couple of suggestions: 1. Don't write down passwords in a file unencrypted (because what you're suggesting is that encryption would only be necessary during display, i.e, when the file is loaded) 2. Don't write down passwords at all - use phrases that you remember instead 3. Don't write down passwords where other people might walk by and see what you're typing nikolai
Re: BOF Vim 8 - EncryptLine
John Beckett wrote:
Suggested new feature:
Make an easy way to encrypt a secret within a line.
Then you can have a simple text file to document stuff, with
embedded secrets. On reading, you only need to enter a key if you
want to see a secret.
Example lines before encryption:
server12 { admin topsecret } any text
mybank { account 123456789 pin 1234 }
Example lines after encryption:
server12 {~8vP09fb3+Pn6+/z9/v8AAwocSE9cDYPAYJUThgE} any text
mybank {~afSDKoy9saGMCZ91x6F7pHkwdzEcMBoGCSqGSIb3DQEJ}
When viewing a file with encrypted secrets, it doesn't matter if
others are shoulder surfing. You only need to get rid of onlookers
for the short time it would take to enter a key and view a secret in
the message line (which would not change the file).
I implemented this scheme in an obsolete editor many years ago,
and offer the suggestion in case it appeals to Bram. However, as
noted in my Suggestions message, I think new features should be
resisted in favour of fixups, so I won't be offended if this is
ignored.
A more detailed description of the proposal follows.
A secret is entered between { and } on a single line.
There is a space after the opening brace.
The encrypted result is stored as base64 text, with ~ inserted as
the first character. The space (plaintext) and tilde (ciphertext)
are safety checks so text is not encrypted or decrypted twice.
These commands would be required:
EnterKey - Prompt user to enter a key for encryption/decryption.
EncryptLine - Encrypt text inside braces on the current line.
DecryptLine - Reverse EncryptLine.
ShowSecret - Show decrypted secret in the message line.
EnterKey prompts the user and allows them to enter a key (no echo).
The key is hashed, and the hash is retained in memory for this
session. It can be cleared by using EnterKey to enter a blank key.
The hashed key is used for any subsequent encryption and decryption.
EncryptLine checks that the current line contains { (with space),
followed by }. It then uses the hashed key to encrypt the text
between the braces, then replaces that text in the current line with
a base64 encoded form of the ciphertext.
EncryptLine inserts a tilde (~) after the first brace. This is a
safety mechanism so you won't accidentally encrypt a line twice.
EncryptLine inserts a small amount of random padding (salt). The
padding is of variable length so the length of the secret is not
known to intruders. However, there is only a small amount of padding
so the result is fairly compact.
ShowSecret decrypts the secret in the current line, and displays the
plaintext in the message line. The file is not changed. There should
be an easy way to put the plaintext in the clipboard, and an easy
way to blank the displayed secret.
DecryptLine reverses EncryptLine, changing the current line. It does
nothing (apart from display an error) if the result is not
reasonable (the ciphertext must be a tilde followed by base64, and
the decryption should satisfy certain sanity checks, and should
yield printable text starting with a space). This is a safety check
to avoid losing data if the wrong key is used to decrypt.
This is very a specific feature. You should implement this in a script,
this doesn't sound like something Vim should support internally.
--
A day without sunshine is like, well, night.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: BOF Vim 8 - EncryptLine
John Beckett wrote:
Suggested new feature:
Make an easy way to encrypt a secret within a line.
Then you can have a simple text file to document stuff, with
embedded secrets. On reading, you only need to enter a key if you
want to see a secret.
Example lines before encryption:
server12 { admin topsecret } any text
mybank { account 123456789 pin 1234 }
Example lines after encryption:
server12 {~8vP09fb3+Pn6+/z9/v8AAwocSE9cDYPAYJUThgE} any text
mybank {~afSDKoy9saGMCZ91x6F7pHkwdzEcMBoGCSqGSIb3DQEJ}
When viewing a file with encrypted secrets, it doesn't matter if
others are shoulder surfing. You only need to get rid of onlookers
for the short time it would take to enter a key and view a secret in
the message line (which would not change the file).
I implemented this scheme in an obsolete editor many years ago,
and offer the suggestion in case it appeals to Bram. However, as
noted in my Suggestions message, I think new features should be
resisted in favour of fixups, so I won't be offended if this is
ignored.
A more detailed description of the proposal follows.
A secret is entered between { and } on a single line.
There is a space after the opening brace.
The encrypted result is stored as base64 text, with ~ inserted as
the first character. The space (plaintext) and tilde (ciphertext)
are safety checks so text is not encrypted or decrypted twice.
These commands would be required:
EnterKey - Prompt user to enter a key for encryption/decryption.
EncryptLine - Encrypt text inside braces on the current line.
DecryptLine - Reverse EncryptLine.
ShowSecret - Show decrypted secret in the message line.
EnterKey prompts the user and allows them to enter a key (no echo).
The key is hashed, and the hash is retained in memory for this
session. It can be cleared by using EnterKey to enter a blank key.
The hashed key is used for any subsequent encryption and decryption.
EncryptLine checks that the current line contains { (with space),
followed by }. It then uses the hashed key to encrypt the text
between the braces, then replaces that text in the current line with
a base64 encoded form of the ciphertext.
EncryptLine inserts a tilde (~) after the first brace. This is a
safety mechanism so you won't accidentally encrypt a line twice.
EncryptLine inserts a small amount of random padding (salt). The
padding is of variable length so the length of the secret is not
known to intruders. However, there is only a small amount of padding
so the result is fairly compact.
ShowSecret decrypts the secret in the current line, and displays the
plaintext in the message line. The file is not changed. There should
be an easy way to put the plaintext in the clipboard, and an easy
way to blank the displayed secret.
DecryptLine reverses EncryptLine, changing the current line. It does
nothing (apart from display an error) if the result is not
reasonable (the ciphertext must be a tilde followed by base64, and
the decryption should satisfy certain sanity checks, and should
yield printable text starting with a space). This is a safety check
to avoid losing data if the wrong key is used to decrypt.
John
John,
Since this requires the file to contain markup characters on the line,
its usefulness is limited in source files where the tags { and } would
cause a syntax error and cannot be marked as comments. As long as this
limitation is acceptable, I think it might me equally as useful and
perhaps more simple and intuitive if instead foldmarkers were used
along with the fold commands (zc, zo):
Password fold exposed:
?php
$admin_password = /*{{{*/ 'maryhadababyitsaboy' /*}}}*/ ;
?
Password fold closed:
?php
+-- 1 line: $admin_password = * ;
?
This has some advantages:
- Less work for the user to visibly protect screen content (no
passwords, etc).
- Reuses existing keyboard sequences: zc, zo, zm, zr, zM, zR, etc...
- Only extends existing functionality (folding -- support for
single-line folds would need to be added)
- Count of *'s is indicative of length of hidden area (user can add
whitespace padding to obscure when desired)
- The obscuration character (*) could be configurable, perhaps as a
multi-character seq, e.g. '**', to also help obscure length.
- Source code is still readable (e.g. the reader is still able to see
that an assignment is occurring and on what variable)
- mkview will cause the fold state to be remembered, to be recalled
later, perhaps automatically when the file is reopened.
This can already be done with traditional multi-line folds:
?php
// {{{ $admin_password = '***';
$admin_password = 'maryhadababyitsaboy';
// }}}
?
to become:
?php
+-- 3 Lines: $admin_password = '***'; ---
?
Must my $0.02.
-Robert
