World: r3wp

Some code for hashing and encrypting could be borrowed from PuTTY. 
Anyway, those algorithms are well documented and some of them even 
have public domain implementations (like MD5).

The RFC for TLS (Transport Layer Security) is 100 pages:
http://tools.ietf.org/html/rfc5246


Is it necessary to implement TLS these days, or is its predecessor 
(SSL) enough?

Too bad, it's such a load to implement some security. :/

Would it make more sense to implement such protocols in REBOL, which 
may be easily portable to Red? (Instead of doing a C implementation.)

I think it would be doable to implement SSL/SSH in REBOL, but it's 
a big task (at least for SSL).

What would be cool would be to implement all the low-level encryption 
routines in Red/System.

Have you looked at the way, REBOL do it? The REBOL/SDK at least have 
some of that security.

REBOL provides all the low-level encryption routines required, but 
they are coded in C.  REBOL SSL implementation is also done in C 
(by Holger IIRC).

ok

The REBOL SSL port might also be using some REBOL code for higher 
level protocol support, but it's not accessible, so we can't check 
that.

IIRC, Cyphre once said, that idea for R3 was to add some port or 
other low level encryption functionality, and that https etc would 
be done in REBOL level, using thow low-level facilities ...

Geomol, the recent exploits of SSL don't affect TLS (at least 1.1 
iirc). So yes, we need to implement TLS, but maybe not SSL.

Has the PuTTY code been updated to patch the latest exploits?

Some serious bugs seem to have been fixed in the latest release: 
http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html

Including PolarSSL in Red would not only require every Red program 
to provide the library source code, it would require every Red program 
to be open source. That's unacceptable for business purposes

As far as I know, OpenSSL is the only TLS implementation under BSD, 
but it's the old BSD licence with advertising clause. This makes 
it incompatible with GPL software such as libraries one may want 
to use with Red, if they don't have an explicit exception for OpenSSL

Much GPL software that is relevant has that exception, so it's a 
limited problem

From a technical standpoint, Jaromil has advised me that GNU TLS 
is of higher quality. It is LGPL, so it's acceptable as long as you 
agree to provide the source code to GNU TLS only, as with many other 
libraries

It would be great to eventually implement many libraries in Red, 
but this is a gargantuan task, and security code is very specialised 
and critical

GnuTLS is indeed of _much_ higher quality than OpenSSL. It is not 
as widespread, though.

Kaj: you're right, I misunderstood the extend of article 2.4 in License 
Exception. We can't use it.

Apparently, PuTTY has its own BSD SSL implementation, so that's interesting. 
But it's not structured as a library, but entirely integrated in 
the other protocols, seems somewhat limited and lacking in portability. 
The only way to use it would be to rip out the source code and make 
a portable library out of it, or reimplement it in Red

Kaj, can you see, if it's a SSL implementation or just SSH? Or is 
SSL there by automatic, when making SSH implementations?

There is hardly any talk of SSL, but of the separate authentication 
methods that it comprises. Indeed, SSH implies what is called SSL, 
so it's in there in some form

Thanks!

It could be completely entangled with the SSH protocol, but since 
they also do SFTP, one can hope it is somewhat abstracted internally

SFTP is basically nothing more than a set of specific commands sent 
over SSH.

That alone won't require much abstraction, I fear.

Ah, right, so it could still be entangled. I was thinking of FTPS

AFAIK, SSL and SSH are different communication protocols that rely 
on common hashing and encryption algorithms on the low-level layer.

Yes, it doesn't seem to be called SSL within SSH, but there is talk 
of TLS

Didn't PuTTY also do telnet/ssl?

Hmm, seems it doesn't.

Well, then there's probably hardly anything SSL/TLS-specific in there, 
except for some common crypto primitives as Doc mentioned.

There is a "telnet.c" in the PuTTY sources.

I have just bricked my Sheevaplug by doing a simple "apt-get upgrade"...:-(

No way to get access to it anymore even using the USB direct connection.

So I need to find a suitable ARM emulator now to be able to finish 
the ARM port...

No warranty?

Seem to be several howtos on how to unbrick a sheevaplug

Warranty: I don't think that warranties apply on "bricked" hardware, 
anyway, I never rely on warranties.

I will see if I can setup QEMU to emulate an ARM and install a suitable 
Linux image over it.

Can not be reflashed ?

http://myubuntublog.wordpress.com/tag/sheevaplug/

Yes it can, but the procedure is long and complicated. It also requires 
a USB stick that will be recognized by the sheeva.

I can't get the QEMU network emulation to work at all...

Just spent my whole day trying to make QEMU work fully, I'm giving 
up that option for now. I will try tomorrow to get my sheeva back 
to life.

Never trust update systems

I've been working on a GoboLinux upgrade for the past days after 
nuking my installation, and there are all sorts of problems

Got networking partially working with QEMU, let's see if it's enough 
to setup the tools I need.