Adding encryption support to vi(1)

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

Adding encryption support to vi(1)

andrew fabbro
vim (in ports) offers an encryption option (
http://vimdoc.sourceforge.net/htmldoc/editing.html#encryption)

Invoking vim with -x prompts for a key and then encrypts the file on save.
It appears to do the right thing as far as encrypting the .swp (temporary
recovery) file as well.  If you later edit the file (without the -x option)
it will detect the file is encrypted based on a magic it prepends and
prompt for a key.

Unfortunately, by default vim uses the 'zip' algorithm which is quite
insecure, though you can optionally specify blowfish as your preferred
algorithm.

The nice thing about this versus a gpg decrypt/edit/re-encrypt cycle is
that you don't have an unencrypted file temporarily lying around (or an
unencrypted vi-recover file for that matter).

I'm wondering if there is any interest in adding this feature to vi(1)
given OpenBSD's interest in integrated crypto?

Unfortunately, as a US citizen/resident, it's not clear to me that I would
be able to contribute code (beyond an implementation that uses the zip
algorithm) so it is probably a moot point unless one of the devs is
interested but...I figured there was no harm in mentioning it.


--
andrew fabbro
[hidden email]
blog: https://raindog308.com

Reply | Threaded
Open this post in threaded view
|

Re: Adding encryption support to vi(1)

Theo de Raadt
>vim (in ports) offers an encryption option (
>http://vimdoc.sourceforge.net/htmldoc/editing.html#encryption)
>
>Invoking vim with -x prompts for a key and then encrypts the file on save.
>It appears to do the right thing as far as encrypting the .swp (temporary
>recovery) file as well.  If you later edit the file (without the -x option)
>it will detect the file is encrypted based on a magic it prepends and
>prompt for a key.
>
>Unfortunately, by default vim uses the 'zip' algorithm which is quite
>insecure, though you can optionally specify blowfish as your preferred
>algorithm.
>
>The nice thing about this versus a gpg decrypt/edit/re-encrypt cycle is
>that you don't have an unencrypted file temporarily lying around (or an
>unencrypted vi-recover file for that matter).
>
>I'm wondering if there is any interest in adding this feature to vi(1)
>given OpenBSD's interest in integrated crypto?

So you describe something which is shit.  Why would we want to add
something shit to vi?  It would fool people into bad practices.  Who
benefits?  Exactly.  Can I ask what kind of plant are you?  Sorry, just
being funny.  Funny ironic.

Reply | Threaded
Open this post in threaded view
|

Re: Adding encryption support to vi(1)

RichardET
In reply to this post by andrew fabbro
I live in NJ. Should I be‎ this paranoid, that every file I edit should be encrypted?
Who has time for this type of craziness?


Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: andrew fabbro
Sent: Friday, December 26, 2014 1:25 AM
To: [hidden email]
Subject: Adding encryption support to vi(1)

vim (in ports) offers an encryption option (
http://vimdoc.sourceforge.net/htmldoc/editing.html#encryption)

Invoking vim with -x prompts for a key and then encrypts the file on save.
It appears to do the right thing as far as encrypting the .swp (temporary
recovery) file as well. If you later edit the file (without the -x option)
it will detect the file is encrypted based on a magic it prepends and
prompt for a key.

Unfortunately, by default vim uses the 'zip' algorithm which is quite
insecure, though you can optionally specify blowfish as your preferred
algorithm.

The nice thing about this versus a gpg decrypt/edit/re-encrypt cycle is
that you don't have an unencrypted file temporarily lying around (or an
unencrypted vi-recover file for that matter).

I'm wondering if there is any interest in adding this feature to vi(1)
given OpenBSD's interest in integrated crypto?

Unfortunately, as a US citizen/resident, it's not clear to me that I would
be able to contribute code (beyond an implementation that uses the zip
algorithm) so it is probably a moot point unless one of the devs is
interested but...I figured there was no harm in mentioning it.


--
andrew fabbro
[hidden email]
blog: https://raindog308.com

Reply | Threaded
Open this post in threaded view
|

Re: Adding encryption support to vi(1)

andrew fabbro
In reply to this post by Theo de Raadt
On Fri, Dec 26, 2014 at 12:02 AM, <[hidden email]> wrote:

> I live in NJ. Should I be‎ this paranoid, that every file I edit should
be
> encrypted?
> Who has time for this type of craziness?
>

Well, no one.  I encrypt very few files.

But keeping one's passwords and related administrivia safe, preventing
unencrypted versions/tempfiles from accidentally being captured by running
backups, etc. is hardly a rare use case.

pwsafe (referring to the nox11 version) is a fine program but comes up a
bit short if you want to include notes that are more than a brief comment,
or what you want to save is not password/account-related. That's really all
I was describing.

On Thu, Dec 25, 2014 at 11:07 PM, Theo de Raadt <[hidden email]>
wrote:

> So you describe something which is shit.  Why would we want to add
> something shit to vi?  It would fool people into bad practices.  Who
> benefits?  Exactly.


Is there no middle ground between an encrypted partition and plain text?
That's an honest question.

Short of encrypting a partition, most tools (gpg, etc.) require decrypting
a file to plain text and then reencrypting.  I was just trying to avoid
having to create unencrypted temporary/intermediate/recovery copies of
files as part of the editing process.

Can I ask what kind of plant are you?


Most people have to content themselves with the "I Got Flamed By Theo de
Raadt
<http://www.zazzle.com/i_got_flamed_by_theo_de_raadt_t_shirt-2354533488287291
21>"
shirt, but I seem to have qualified for the new "Theo de Raadt Asked if I
Was a Spy" shirt :-)

--
andrew fabbro
[hidden email]
blog: https://raindog308.com

Reply | Threaded
Open this post in threaded view
|

Re: Adding encryption support to vi(1)

Marc Espie-2
In reply to this post by andrew fabbro
There's already a kitchen sink, it's called emacs.

Reply | Threaded
Open this post in threaded view
|

Re: Adding encryption support to vi(1)

Theo de Raadt
In reply to this post by andrew fabbro
> Is there no middle ground between an encrypted partition and plain text?

Adding low-grade encrypt-with-password to lots of utilities like this
does not make sense.

Reply | Threaded
Open this post in threaded view
|

Re: Adding encryption support to vi(1)

Joel Rees-2
In reply to this post by andrew fabbro
On Sat, Dec 27, 2014 at 1:33 AM, andrew fabbro <[hidden email]> wrote:
> On Fri, Dec 26, 2014 at 12:02 AM, <[hidden email]> wrote:
>
>> I live in NJ. Should I be‎ this paranoid, that every file I edit should
> be
>> encrypted?
>> Who has time for this type of craziness?
>
> Well, no one.  I encrypt very few files.

I think that's relevant.

> But keeping one's passwords and related administrivia safe, preventing
> unencrypted versions/tempfiles from accidentally being captured by running
> backups, etc. is hardly a rare use case.

Let's draw a venn diagram of uses of vi and uses of a text editor
capable of directly writing encrypted files.

(Don't get me wrong. When I first read your original question, I was
thinking, yeah, I might want one of those ./)

> pwsafe (referring to the nox11 version) is a fine program but comes up a
> bit short if you want to include notes that are more than a brief comment,
> or what you want to save is not password/account-related. That's really all
> I was describing.
> [...]

Do one thing, do it well.

Otherwise, it becomes difficult to prove correctness.

Simple text editors are not hard to write, especially if you decide to
not deal with variable width typefaces and such. I'd whip one up for
you, but right now I'd probably be writing it in forth. 8-*

Of course, gpg reads from standard input, so ...

--
Joel Rees

Be careful when you look at conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.
Arm yourself with knowledge of yourself, as well.