Libcrypt examples?

Ronald F. Guilmette rfg at
Fri Oct 17 01:54:47 CEST 2014

In message <54401557.1030105 at>, 
"Robert J. Hansen" <rjh at> wrote:

>> I have a program that will frequently need to store modest-size
>> chunks of of data on disk, perhaps 1-4kB per chunk.  The data is
>> sensitive, but not ultra top secret.  I would like to make a
>> reasonable effort to keep it from prying eyes.
>Please don't take this the wrong way, but -- please don't.  Libgcrypt is
>not particularly friendly to novices.  It exposes a *lot* of dials and
>switches in the interests of letting experts do weird and useful things.
> Novices will be better-suited with something like Peter Gutmann's
>cryptlib, which is high-quality and well-regarded and is probably more

This is helpful.  Very much so.  Thank you.  I will quite certainly
look into that other library.

(I am not at all ashamed to admit than in the realm of crypto generally,
I *do* most probably qualify as a "newbie", or perhaps at best a Padawan.)

>> P.S.  On my FreeBSD system, un-updated as it may be, there seems
>> to be a crypt(3) in the standard C library.
>I believe on FreeBSD this is just bog-standard DES, but I could be
>mistaken.  DES is not a strong cipher.

Yes, I believe that I saw some public comments somewhere to that effect,
i.e. the part about DES being not-so-hot-anymore.

>> Fortunately, I *do* have something that's a bit faster than A Pentium 166
>> :-) but I'm still rather baffled by the meaning of the phrase "designed
>> to be time-consuming" in this context.
>To help foil brute-force attacks.  crypt(3) is normally used with really
>short pieces of text -- passwords.  As such, one way to attack passwords
>is to get a large dictionary of words and run each word through crypt(3)
>and store the result.  If you want to break a password, look at its
>crypt(3)ed value and compare it to your database of computed values.  If
>you get a hit, then look back at what the original word was.
>To foil these sorts of attacks ("dictionary attacks"), crypt(3) has been
>built to be very, very slow.

OK.  Thanks!  I got it.  So just as a literal reading of the man page
would suggest, the thing is indeed slow for *everybody* and not just an

That slowness is sure to be helpful in the context you elaborated, but
for my purposes it would definitely be entirely unhelpful.  Thus, as
you've helped me to understand, I best bet is to steer clear os using
that one within the thing I'm building.

Thanks again.


More information about the Gnupg-users mailing list