[Conversation on srfi-discuss that it'd make sense to write a SSL pipe
SRFI, it should support specifying acceptable SSL versions and other
parameters, and who should write the document.]

> Thanks for asking.  I'd be happy to help by editing, but I'm not willing to
> commit to writing or implementing anything.  This is for two reasons:
> first, I'm supposed to maintain my editorial independence, and second, and
> selfishly, I'm trying hard to find time for my long-term projects, so I
> don't want to commit to new projects.  Thank you for your understanding.

No problem. I can write a draft and others can then point out my
mistakes :D However, it will take a while since I have a backlog of
several other SRFIs to finish. If someone else wants to write the SSL
pipe SRFI earlier, feel free to do so.

>> I agree that it's good that crypto implementations start popping up in
>> non-C languages. However, one problem is that it's hard to wipe secret
>> data from memory in a GC'ed language.
>
> Yes, that's definitely an issue.  It would certainly require non-portable
> (or currently non-portable) facilities.  For example, key material might be
> kept in non-moving memory that is wiped upon release.

That sounds like a good idea. However, the program also has to be able
to control the lifetime of the data so that it can guarantee that
there's no secret data left past a particular point.

Another problem that C programmers have had to face is preventing secret
data from ending up in core dumps. IIRC OpenBSD added a MAP_CONCEAL flag
to mmap(): <http://man.openbsd.org/mmap>. Memory mapped with that flag
doesn't get written into core dumps. There's also malloc_conceal() and
calloc_conceal() for friendlier interfaces.

> I'm not sure what
> even C programs do about secret strings, for example, that are manipulated
> in the program.  Are they careful to wipe them every time they're
> released?

They zero the memory when they no longer need it, with special functions
that guarantee the compiler and malloc implementation don't optimize out
any of the zeroing. There used to be a particular problem with GCC
optimizing out bzero() or memset(x, 0, n) calls. OpenBSD added the
explicit_bzero() and freezero() functions for this purpose
(<http://man.openbsd.org/explicit_bzero> and
<http://man.openbsd.org/freezero>).

> It would be nice to have some general mechanism for solving this
> problem once and for all.

Definitely. It has to be very tightly coupled with the GC implementation
and I expect it will be difficult even for a GC expert to pull of, but
eventually somebody has to do it and it has to spread. A quick Google
Scholar search didn't find any papers :-/ You might want to ask the MIT
Scheme folks if they have any ideas.

Perhaps a mechanism similar to weak pointers would work.

 From the Chez Scheme manual: "If at some point the garbage collector
recognizes that there are no nonweak pointers to the object, however, it
replaces each weak pointer to the object with the "broken weak-pointer"
object, #!bwp, and discards the object. "

There could be a (call-with-secret (lambda (foo) ...)) guaranteeing that
the secret object "foo" is wiped out after the lambda returns. If the
object escapes the extent of the call, anyone trying to get its value
outside that extent would get some dummy value similar to the #!bwp
value. Only inside the extent would the real value be returned.

> Incidentally, this discussion should probably move to Schemeweb.
> Srfi-discuss is more for discussion of the SRFI process than for the
> specifics of particular proposals.  I want to make sure that participants
> aren't overwhelmed by the level of traffic.

Cross-posting this message to both lists; please remove srfi-discuss
from any replies.