Re: [Nano-devel] Nano-devel Digest, Vol 167, Issue 15

[spammuck]

I already responded to those who emailed me.
But it now seems that my response should go here.
If I am violating protocol, then I am sure that you will let me know.

So, responding to Mike:-
> while nifty, i'm not sure this makes sense for nano to do. seems like
> it's pretty far outside the scope of nano itself. for example, why just
> zlib ? why not bzip2/lzma/lz4/xz/compress/etc... ? what about archives
> and not just compressed files (e.g. tar/zip/rar/7z/etc...) ? what about
> other encryption algorithms beyond AES ?
>
> seems like nano should be a text editor and filtering of file formats
> should be left to other tools. it's not like nano having read access
> makes it more secure ... if someone has root on the system, they can
> dump the memory of nano as easily as a file your user owns.
> -mike
Will take no for an answer.  But the cloud does not have root access to
my PC.  Someone inspecting my drive after I have used my PC might not be
able to see what used to be in memory.  I find it very handy.  Before I
modded nano, I used that feature from Vim.  But I was not entirely happy
with that feature in Vim, so I added what I wanted to nano.


Responding to Benno:-
> There is a tool that can do encryption pretty well: gpg. And several
> tools that can do compression. All that needs to be done is pipe these
> tools together in a little script so you can decrypt a file into nano
> without any intermediate temporary file (already possible by using the
> "-" argument to nano), and then encrypt the buffer again back to disk.
> For that latter part, nano needs to grow the ability to write a buffer
> to standard out. See https://savannah.gnu.org/bugs/?27346 for the
> relevant feature request.

Will take no for an answer.
 
> Well, let's first see what your patch against 2.2.5 looks like, so we
> have some idea of magnitude to the changes you made.

OK. Have attached tarred gzipped "make clean" director "src".


Responding to Lion:-
> I am a bit worried about the command line with secret (key for
> encryption)… It can be found very easily at .bash_history. That is,
> using command line to pass the key is very likely vulnerable. But
> anyways, I think it is useful to do simple encryption for something like
> diary or cloud storage as you mentioned.

I use nano's display bar, not the command line.
The user types the secret key into nano's display bar.
It currently uses nano's available function for doing that.
The characters typed are currently shown, not replaced with asterisks.

> BTW, what block cipher mode are you using?

I use a more general framework permitting the adding in of any cypher.
The code has to register a cypher.  My code currently registers 3 cyphers.

"-P 0" -> compression only.
"-P 1" -> AES128
"-P 2" -> AES256
"-P 3" (currently the default) shown below.

I was never quite happy with CBC.  But it can be accommodated.  The
framework is not so opinionated (unlike me).

You probably wont like, but what I did in the 3 cyphers that I
provided is :-  I group the block into buffers of 256 bytes and ex-or
the bytes of the buffer with a long stream digest of the key before
applying encryption.

"-P 3" Triple AES

A means AES128.
[] means one block (16 bytes)
..||.. means interleaving of bytes, reblocking the bytes so that each of
        the 16 blocks in the new buffer will consist of one byte from each of
        the blocks in the old buffer.

[] -> A -> []   ..||..   [] -> A -> []    ..||..   [] -> A -> []
[] -> A -> []   ..||..   [] -> A -> []    ..||..   [] -> A -> []
   ...
[] -> A -> []   ..||..   [] -> A -> []    ..||..   [] -> A -> []

temp.tgz
Description: application/compressed-tar