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
