Hello all, I’ve been looking into FIPS
but couldn’t help falling over the Squeak Pluggin for OpenSSL and
Stunnel. https://lists.wisc.edu/read/messages?id=181840 https://lists.wisc.edu/read/messages?id=183375 I haven’t tried them yet but was wondering
if anyone else has. Does it make sense to move forward with our own FIPS
certification, or would it make sense to tightly integrate both openSSL and
Stunnel into squeak instead? Does anyone have any thoughts about the benefits and
drawbacks of having the cryptographic code be an external black box? Are
there greater benefits to our having implemented our own code, for education
and flexibility … ? Personally I would prefer having the code
be in squeak, but I thought the question worth asking. Should we do both? Thoughts? Ron Teitelbaum Squeak Cryptography Team Leader _______________________________________________ Cryptography mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
"Ron Teitelbaum" <[hidden email]> wrote:
> Does anyone have any thoughts about the benefits and drawbacks of having the > cryptographic code be an external black box? Are there greater benefits to > our having implemented our own code, for education and flexibility . ? > Personally I would prefer having the code be in squeak, but I thought the > question worth asking. Should we do both? A quibble: stunnel _uses_ OpenSSL, so stunnel doesn't provide us with anything more as far as crypto's concerned (at least, AFAIK). OpenSSH, on the other hand, is quite another story. And I'd love to see those services available in Squeak! I think we should do both: a plugin wrapper allows us to provide strong crypto relatively quickly. Then for True Fans, we can write Smalltalk-only code and then either slowly phase out the plugins function by function, or simply allow people to choose. Oh, and having plugins will provide us with handy in-Squeak reference implementations. My main worry with implementing our code is simply that OpenSSL and OpenSSH have been beaten upon for a long time; while we do see advisories coming out for them, they're few and far between. frank _______________________________________________ Cryptography mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
Squeak-Crypto-Gods,
I am dying (begging/praying/pleading) for a complete native Squeak implementation of OpenSSL and OpenSSH. They will soon be needed for the SqueakNOS project where we don't have access to the services of an underlying OS. Of course SqueakNOS will be fine without it but a whole bunch of new opportunities open up with that functionality in place. I also agree with Franks comments that advisories are now few and far between but of course I am saying that as someone who doesn't have the skills to either create the port or maintain the code so it's rather too easy for me to say ;) Johnathon ----- Original Message ----- From: "Frank Shearar" <[hidden email]> To: "Cryptography Team Development List" <[hidden email]> Sent: Thursday, July 13, 2006 8:42 AM Subject: Re: [Cryptography Team] OpenSSL, Stunnel > "Ron Teitelbaum" <[hidden email]> wrote: > >> Does anyone have any thoughts about the benefits and drawbacks of having > the >> cryptographic code be an external black box? Are there greater benefits > to >> our having implemented our own code, for education and flexibility . ? >> Personally I would prefer having the code be in squeak, but I thought the >> question worth asking. Should we do both? > > A quibble: stunnel _uses_ OpenSSL, so stunnel doesn't provide us with > anything more as far as crypto's concerned (at least, AFAIK). OpenSSH, on > the other hand, is quite another story. And I'd love to see those services > available in Squeak! > > I think we should do both: a plugin wrapper allows us to provide strong > crypto relatively quickly. Then for True Fans, we can write Smalltalk-only > code and then either slowly phase out the plugins function by function, or > simply allow people to choose. Oh, and having plugins will provide us with > handy in-Squeak reference implementations. > > My main worry with implementing our code is simply that OpenSSL and > OpenSSH > have been beaten upon for a long time; while we do see advisories coming > out > for them, they're few and far between. > > frank > > _______________________________________________ > Cryptography mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography > _______________________________________________ Cryptography mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
In reply to this post by Ron Teitelbaum
> Does anyone have any thoughts about the benefits and drawbacks of
> having the > cryptographic code be an external black box? Are there greater > benefits to > our having implemented our own code, for education and flexibility . > ? > Personally I would prefer having the code be in squeak, but I thought > the > question worth asking. Should we do both? I think both is good. Public black-box implementations are good for those who just want to be more secure and not have to think about it. These are much more hacked upon which is good for scrutiny, but bad when problems are found. FYI, someone sent me this "advisory" claiming an exposure to the RNG used by TLS/SSL key generation. http://www.gutterman.net/publications/GuttermanPinkasReinman2006.pdf OTOH, I very much want to _understand_ the security, the best way for me to do that is to get my hands dirty with our own code. I think understanding the why's goes far toward being able to make a secure system. It also seems less likely simpler, less-popular protocols would, let alone could, be hacked since hackers probably want the glory of breaking the "big" ones.. But this is a foolish thought to have.. :) - Chris PS - One more problem with "external" black-box is its externality. Assuming you trust the black box, you still have to release sensitive information into the communication-pipes of the OS to get it to the black box.. With internal security, The attacker has to hack the memory of the image, because no sensitive information ever leaves the image. _______________________________________________ Cryptography mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
Free forum by Nabble | Edit this page |