From: Rical Jasan <rj@2c3t.io>
To: Zack Weinberg <zackw@panix.com>
Cc: libc-alpha@sourceware.org, carlos@redhat.com, fweimer@redhat.com,
kukuk@suse.de
Subject: Re: [PATCH 1/4] Disallow use of DES encryption functions in new programs.
Date: Wed, 23 May 2018 03:37:00 -0000 [thread overview]
Message-ID: <2c80ca24-a8d6-3220-3745-c43941465393@2c3t.io> (raw)
In-Reply-To: <20180521173853.5172-2-zackw@panix.com>
> diff --git a/manual/crypt.texi b/manual/crypt.texi
...
OK (purely removal).
> diff --git a/manual/string.texi b/manual/string.texi
> index b07cfb4550..a1c58e58fa 100644
> --- a/manual/string.texi
> +++ b/manual/string.texi
> @@ -36,8 +36,8 @@ too.
> for delimiters.
> * Erasing Sensitive Data:: Clearing memory which contains sensitive
> data, after it's no longer needed.
> -* strfry:: Function for flash-cooking a string.
> -* Trivial Encryption:: Obscuring data.
> +* Shuffling Bytes:: Or how to flash-cook a string.
> +* Obfuscating Data:: Reversibly obscuring data from casual view.
OK.
> * Encode Binary Data:: Encoding and Decoding of Binary Data.
> * Argz and Envz Vectors:: Null-separated string vectors.
> @end menu
> @@ -2426,73 +2426,73 @@ functionality under a different name, such as @code{explicit_memset},
> systems it may be in @file{strings.h} instead.
> @end deftypefun
>
> -@node strfry
> -@section strfry
> +
> +@node Shuffling Bytes
> +@section Shuffling Bytes
>
> The function below addresses the perennial programming quandary: ``How do
> I take good data in string form and painlessly turn it into garbage?''
> -This is actually a fairly simple task for C programmers who do not use
> -@theglibc{} string functions, but for programs based on @theglibc{},
> -the @code{strfry} function is the preferred method for
> -destroying string data.
> +This is not a difficult thing to code for oneself, but the authors of
> +@theglibc{} wish to make it as convenient as possible.
I don't think this introduction needed to be changed, but the new text
is tongue-in-cheek enough that I'm OK with it.
> -The prototype for this function is in @file{string.h}.
> +To @emph{erase} data, use @code{explicit_bzero} (@pxref{Erasing
> +Sensitive Data}); to obfuscate it reversibly, use @code{memfrob}
> +(@pxref{Obfuscating Data}).
Good addition.
> @deftypefun {char *} strfry (char *@var{string})
> @standards{GNU, string.h}
> @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
> @c Calls initstate_r, time, getpid, strlen, and random_r.
>
> -@code{strfry} creates a pseudorandom anagram of a string, replacing the
> -input with the anagram in place. For each position in the string,
> -@code{strfry} swaps it with a position in the string selected at random
> -(from a uniform distribution). The two positions may be the same.
> +@code{strfry} performs an in-place shuffle on @var{string}. Each
> +character is swapped to a position selected at random, within the
> +portion of the string starting with the character's original position.
> +(This is the Fisher-Yates algorithm for unbiased shuffling.)
I like the "pseudorandom anagram" analogy, personally, as it's
rearranging a string. What about combining the two? I'm not sure we
even need to go into this much detail about how it happens, though I do
think it's good to mention that it happens "in-place" (which both
versions do). What about:
@code{strfry} creates a pseudorandom anagram of @var{string}, replacing
it in-place using the Fisher-Yates algorithm for unbiased shuffling.
> +Calling @code{strfry} will not disturb any of the random number
> +generators that have global state (@pxref{Pseudo-Random Numbers}).
Another good addition.
> The return value of @code{strfry} is always @var{string}.
>
> @strong{Portability Note:} This function is unique to @theglibc{}.
> -
> +It is declared in @file{string.h}.
OK.
> @end deftypefun
>
>
> -@node Trivial Encryption
> -@section Trivial Encryption
> -@cindex encryption
> -
> -
> -The @code{memfrob} function converts an array of data to something
> -unrecognizable and back again. It is not encryption in its usual sense
> -since it is easy for someone to convert the encrypted data back to clear
> -text. The transformation is analogous to Usenet's ``Rot13'' encryption
> -method for obscuring offensive jokes from sensitive eyes and such.
> -Unlike Rot13, @code{memfrob} works on arbitrary binary data, not just
> -text.
> +@node Obfuscating Data
> +@section Obfuscating Data
> @cindex Rot13
>
> -For true encryption, @xref{Cryptographic Functions}.
> +The @code{memfrob} function reversibly obfuscates an array of binary
> +data. This is not true encryption; the obfuscated data still bears a
> +clear relationship to the original, and no secret key is required to
> +undo the obfuscation. It is analogous to the ``Rot13'' cipher used on
> +Usenet for obscuring offensive jokes, spoilers for works of fiction,
> +and so on, but it can be applied to arbitrary binary data.
>
> -This function is declared in @file{string.h}.
> -@pindex string.h
> +Programs that need true encryption---a transformation that completely
> +obscures the original and cannot be reversed without knowledge of a
> +secret key---should use a dedicated cryptography library, such as
> +@uref{https://www.gnu.org/software/libgcrypt/,,libgcrypt}.
> +
> +Programs that need to @emph{destroy} data should use
> +@code{explicit_bzero} (@pxref{Erasing Sensitive Data}), or possibly
> +@code{strfry} (@pxref{Shuffling Bytes}).
>
> @deftypefun {void *} memfrob (void *@var{mem}, size_t @var{length})
> @standards{GNU, string.h}
> @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
>
> -@code{memfrob} transforms (frobnicates) each byte of the data structure
> -at @var{mem}, which is @var{length} bytes long, by bitwise exclusive
> -oring it with binary 00101010. It does the transformation in place and
> -its return value is always @var{mem}.
> +The function @code{memfrob} obfuscates @var{length} bytes of data
> +beginning at @var{mem}, in place. Each byte is bitwise xor-ed with
> +the binary pattern 00101010 (hexadecimal 0x2A). The return value is
> +always @var{mem}.
>
> -Note that @code{memfrob} a second time on the same data structure
> -returns it to its original state.
> -
> -This is a good function for hiding information from someone who doesn't
> -want to see it or doesn't want to see it very much. To really prevent
> -people from retrieving the information, use stronger encryption such as
> -that described in @xref{Cryptographic Functions}.
> +@code{memfrob} a second time on the same data returns it to
> +its original state.
>
> @strong{Portability Note:} This function is unique to @theglibc{}.
> -
> +It is declared in @file{string.h}.
> @end deftypefun
OK. Not much really changed in the content, but there was a good bit
that was due for removal.
Good cleanup overall, and good eye catching the additional
"cryptography"-related content.
Thanks,
Rical
next prev parent reply other threads:[~2018-05-23 3:37 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-21 17:39 [PATCH 0/4 v3] libcrypt phaseout Zack Weinberg
2018-05-21 17:39 ` [PATCH 2/4] Reorganize crypt.texi Zack Weinberg
2018-05-23 5:23 ` Rical Jasan
2018-05-21 17:39 ` [PATCH 4/4] New configure option --disable-crypt Zack Weinberg
2018-05-21 19:52 ` Joseph Myers
2018-05-21 22:07 ` Zack Weinberg
2018-05-21 22:34 ` Joseph Myers
2018-05-22 1:08 ` Zack Weinberg
2018-06-20 20:40 ` Florian Weimer
2018-06-20 22:48 ` Zack Weinberg
2018-06-21 9:31 ` Florian Weimer
2018-06-21 9:32 ` Florian Weimer
2018-06-28 18:52 ` Zack Weinberg
2018-05-21 17:39 ` [PATCH 3/4] Revise crypt.texi Zack Weinberg
2018-05-25 2:52 ` Rical Jasan
2018-06-25 12:21 ` Florian Weimer
2018-06-25 12:26 ` Florian Weimer
2018-05-21 17:39 ` [PATCH 1/4] Disallow use of DES encryption functions in new programs Zack Weinberg
2018-05-22 6:58 ` Florian Weimer
2018-05-23 3:37 ` Rical Jasan [this message]
2018-05-23 16:50 ` Joseph Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2c80ca24-a8d6-3220-3745-c43941465393@2c3t.io \
--to=rj@2c3t.io \
--cc=carlos@redhat.com \
--cc=fweimer@redhat.com \
--cc=kukuk@suse.de \
--cc=libc-alpha@sourceware.org \
--cc=zackw@panix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).