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