BOF Vim 8 - EncryptLine

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

BOF Vim 8 - EncryptLine

John Beckett
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
Reply | Threaded
Open this post in threaded view
|

Re: BOF Vim 8 - EncryptLine

Robert Lee-7
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
Reply | Threaded
Open this post in threaded view
|

Re: BOF Vim 8 - EncryptLine

Matthew Winn-3
> 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
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: BOF Vim 8 - EncryptLine

Robert Lee-7
Matthew Winn wrote:
 >> 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
 > <[hidden email]> 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.
 >

Sorry, I was under the impression that the primary purpose of the OP's
suggestion was to prevent people reading over your shoulder from seeing
sensitive information within the file rather than to actually encrypt
the file on disk. I admit that I misunderstood the OP's suggestion.

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).

As far as lengths of the obfuscated character sequence: I couldn't
imagine why it would be unacceptable to use the content-length and give
the author control over obfuscation in cases where it matters (via
extraneous whitespace between the {{{ and }}}). One exception: if the
folded content is wider than screen width it might be ideal to
abbreviate the obfuscated character sequence so that it can be displayed
on a single line.

Just an idea. :o)

-Robert
Reply | Threaded
Open this post in threaded view
|

Re: BOF Vim 8 - EncryptLine

Nico Weber-3
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

Reply | Threaded
Open this post in threaded view
|

Re: BOF Vim 8 - EncryptLine

Robert Lee-7
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
Reply | Threaded
Open this post in threaded view
|

Re: BOF Vim 8 - EncryptLine

Nikolai Weibull-11
In reply to this post by John Beckett
On 1/18/07, John Beckett <[hidden email]> wrote:
> Suggested new feature:
> 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?

  nikolai
Reply | Threaded
Open this post in threaded view
|

Re: BOF Vim 8 - EncryptLine

Nikolai Weibull-11
In reply to this post by Robert Lee-7
On 1/18/07, Robert Lee <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: BOF Vim 8 - EncryptLine

Bram Moolenaar
In reply to this post by John Beckett

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 -- [hidden email] -- 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    ///
Reply | Threaded
Open this post in threaded view
|

Re: BOF Vim 8 - EncryptLine

John Beckett
In reply to this post by Nikolai Weibull-11
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

Reply | Threaded
Open this post in threaded view
|

Re: BOF Vim 8 - EncryptLine

John Beckett
In reply to this post by Bram Moolenaar
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

Reply | Threaded
Open this post in threaded view
|

Re: BOF Vim 8 - EncryptLine

John Beckett
In reply to this post by Nikolai Weibull-11
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

Reply | Threaded
Open this post in threaded view
|

Re: BOF Vim 8 - EncryptLine

Nikolai Weibull-11
On 1/19/07, John Beckett <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: BOF Vim 8 - EncryptLine

Kazuo Teramoto
On 1/19/07, Nikolai Weibull <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: BOF Vim 8 - EncryptLine

Matthew Winn-3
In reply to this post by Nico Weber-3
On Thu, 18 Jan 2007 11:04:00 +0100, Nicolas Weber
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: BOF Vim 8 - EncryptLine

Nikolai Weibull-11
On 1/19/07, Matthew Winn <[hidden email]> 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?

  nikolai

P.S.
Sorry, I couldn't keep from joking around a bit.
D.S.
Reply | Threaded
Open this post in threaded view
|

RE: BOF Vim 8 - EncryptLine

Zdenek Sekera
> From: [hidden email]
> On 1/19/07, Matthew Winn <[hidden email]> 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 (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: BOF Vim 8 - EncryptLine

John Beckett
In reply to this post by Nikolai Weibull-11
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

Reply | Threaded
Open this post in threaded view
|

Re: BOF Vim 8 - EncryptLine

MarcWeber
In reply to this post by John Beckett
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
Reply | Threaded
Open this post in threaded view
|

Re: BOF Vim 8 - EncryptLine

John Beckett
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

12