> 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
