Re: Cryptography
Locked
 
|
Hi David,
I am CCing the squeak-dev list. I had tried to contact Ron over the weekend, since he is the admin for the SqueakSource Cryptography package. I needed to add you as a member of the Crypto team. That's right, you are a member now. I didn't hear from him so the email address may be bad. We'll see if we hear from him in the future. I hope so. Do you have the link to the Crypto mailing list? I agree we should do this in public. I would suggest the squeak-dev list. We may have several "forks" and/or subsequent work done from the root package. The root package for SSL is in the Monticello repository http://www.squeaksource.com/Cryptography, but it may not be the latest. I think that the SSL package there is the latest...Whoa! I just checked again and new SSL packages were inserted 2 days ago. The latest there used to be SSL-rww.4.mcz and now there is a SSL-jrd.12.mcz. The root package for Cryptography is in the same repository, but it is less clear which is the latest and greatest. There is a mixture of version numbers. I am using Cryptography-cmm.13.mcz. All tests pass except for a Rindael test and an X509 test (due to bad validity dates). I know there is packages in http://croquet-src-01.oit.duke.edu:8886/Contributions. SSL look like the ones now in the Cryptography repository above. The Cryptography packages in Contributions look like they are also in the Cryptography repository, but mixed up with other work. In Contributions, there is the sequence of packages: Cryptography-RJT.10.mcz (the root package) Cryptography-jrd.11.mcz Cryptography-jrd.12.mcz Cryptography-mtf.13.mcz These are interwoven with other packages in the Cryptography repository, with the same version numbers. Lastly, David, it sounded like you have developments that you wanted to integrate. Cheers, Rob -------------------------------------------------- From: "C. David Shaffer" <[hidden email]> Sent: Tuesday, June 29, 2010 2:23 PM To: "Rob Withers" <[hidden email]>; "Ron Teitelbaum" <[hidden email]> Subject: Cryptography > Ron and Rob, > > I see that there is a Cryptography mailing list but that there hasn't > been a post since 2009. I would like updates to Cryptography to happen > "in public" since I think a lot of people are interested in these > packages. I can post to either forum. > > Based on what I've seen, integrating work that has been done may take a > few 'back-and-forths' so I just need to know in what forum to raise > questions. > > Finally, I know I'm not part of the Crypto team and I'm no expert in > cryptography or even the Squeak frameworks. What I see, however, is the > there is some code harvesting to be done and I think I can do a little > of it without causing any harm. I'm using SSL and MD5+HMAC heavily > under Squeak3.9 and Squeak4.1 (soon) and so I can exercise parts of the > framework past what is already covered by unit tests. Any other bugs > that I introduce can be fixed by harsh words from those that use those > bits of functionality. > > David > |
|
|
On 06/29/10 22:36, Rob Withers wrote:
> Hi David, > > I am CCing the squeak-dev list. > > I had tried to contact Ron over the weekend, since he is the admin for > the SqueakSource Cryptography package. I needed to add you as a > member of the Crypto team. That's right, you are a member now. I > didn't hear from him so the email address may be bad. We'll see if > we hear from him in the future. I hope so. > > Do you have the link to the Crypto mailing list? > > I agree we should do this in public. I would suggest the squeak-dev > list. > > We may have several "forks" and/or subsequent work done from the root > package. > > The root package for SSL is in the Monticello repository > http://www.squeaksource.com/Cryptography, but it may not be the > latest. I think that the SSL package there is the latest...Whoa! I > just checked again and new SSL packages were inserted 2 days ago. The > latest there used to be SSL-rww.4.mcz and now there is a SSL-jrd.12.mcz. Yes, I copied the mods from the croquet-source repo. SSL was easy as there were no forks. jrd.12 is the version I am using and it is working pretty well. I did have some intermittent failures when I was first moving to Squeak4.1 but those might have been due to errant versions of the Cryptography package. I will do a fresh build and verify this version. > > The root package for Cryptography is in the same repository, but it is > less clear which is the latest and greatest. There is a mixture of > version numbers. I am using Cryptography-cmm.13.mcz. All tests pass > except for a Rindael test and an X509 test (due to bad validity dates). > > I know there is packages in > http://croquet-src-01.oit.duke.edu:8886/Contributions. SSL look like > the ones now in the Cryptography repository above. The Cryptography > packages in Contributions look like they are also in the Cryptography > repository, but mixed up with other work. In Contributions, there is > the sequence of packages: > > Cryptography-RJT.10.mcz (the root package) > Cryptography-jrd.11.mcz > Cryptography-jrd.12.mcz > Cryptography-mtf.13.mcz > > These are interwoven with other packages in the Cryptography > repository, with the same version numbers. Right, there are several forks to be reconciled. FWIW I am running mtf.13 as none of the versions from the original Cryptography repo had ASN.1 support needed to do SSL (SSL30 or TLS10/11). Unfortunately this version fails CryptoX509Test>>testSignatureValidation (as well as the Rindael test you mentioned). I am hoping the harvesting from the other forks will take care of this. At this point all of the croquet-source versions are in their rightful place in the Cryptography project on SqueakSource. The SqueakSource project contains no license information. It would be a very good idea to assign a license so that all contributions to this repo are automatically assigned that license. I think Ron needs to guide this process as this is his baby. At the very least Ron and all other contributors need to be asked to accept whatever license is selected or we will have to re-write those portions. I am happy to try to track everyone down but not without making sure Ron is receptive to this. David |
|
|
--------------------------------------------------
From: "C. David Shaffer" <[hidden email]> Sent: Wednesday, June 30, 2010 12:11 PM To: "The general-purpose Squeak developers list" <[hidden email]>; "Ron Teitelbaum" <[hidden email]>; "Squeak Cryptography" <[hidden email]> Subject: [squeak-dev] Re: Cryptography > On 06/29/10 22:36, Rob Withers wrote: >> Hi David, >> >> I am CCing the squeak-dev list. >> >> I had tried to contact Ron over the weekend, since he is the admin for >> the SqueakSource Cryptography package. I needed to add you as a >> member of the Crypto team. That's right, you are a member now. I >> didn't hear from him so the email address may be bad. We'll see if >> we hear from him in the future. I hope so. >> >> Do you have the link to the Crypto mailing list? > Yes, do we move this discussion there? We can discuss in one or both. Your choice. I think the most visibility will be from discussing it on squeak-dev. > >> >> I agree we should do this in public. I would suggest the squeak-dev >> list. >> >> We may have several "forks" and/or subsequent work done from the root >> package. >> >> The root package for SSL is in the Monticello repository >> http://www.squeaksource.com/Cryptography, but it may not be the >> latest. I think that the SSL package there is the latest...Whoa! I >> just checked again and new SSL packages were inserted 2 days ago. The >> latest there used to be SSL-rww.4.mcz and now there is a SSL-jrd.12.mcz. > > Yes, I copied the mods from the croquet-source repo. SSL was easy as > there were no forks. jrd.12 is the version I am using and it is working > pretty well. I did have some intermittent failures when I was first > moving to Squeak4.1 but those might have been due to errant versions of > the Cryptography package. I will do a fresh build and verify this > version. > Ah, excellent. I also have SSL-jrd.12.mcz loaded. I have one class in SSL that I use in SqueakElib. When I load both, it rips it from one location and places it in another (different categories). Stéphane Ducasse has pointed me to metacello (http://gemstonesoup.wordpress.com/2009/08/25/metacello-package-management-for-monticello/), which is a package management system. It allows one to load dependent packages. You might want to look into it. >> >> The root package for Cryptography is in the same repository, but it is >> less clear which is the latest and greatest. There is a mixture of >> version numbers. I am using Cryptography-cmm.13.mcz. All tests pass >> except for a Rindael test and an X509 test (due to bad validity dates). >> >> I know there is packages in >> http://croquet-src-01.oit.duke.edu:8886/Contributions. SSL look like >> the ones now in the Cryptography repository above. The Cryptography >> packages in Contributions look like they are also in the Cryptography >> repository, but mixed up with other work. In Contributions, there is >> the sequence of packages: >> >> Cryptography-RJT.10.mcz (the root package) >> Cryptography-jrd.11.mcz >> Cryptography-jrd.12.mcz >> Cryptography-mtf.13.mcz >> >> These are interwoven with other packages in the Cryptography >> repository, with the same version numbers. > > Right, there are several forks to be reconciled. FWIW I am running > mtf.13 as none of the versions from the original Cryptography repo had > ASN.1 support needed to do SSL (SSL30 or TLS10/11). Unfortunately this > version fails CryptoX509Test>>testSignatureValidation (as well as the > Rindael test you mentioned). I am hoping the harvesting from the other > forks will take care of this. I need to fix the X509 error. > > At this point all of the croquet-source versions are in their rightful > place in the Cryptography project on SqueakSource. The SqueakSource > project contains no license information. It would be a very good idea > to assign a license so that all contributions to this repo are > automatically assigned that license. I think Ron needs to guide this > process as this is his baby. At the very least Ron and all other > contributors need to be asked to accept whatever license is selected or > we will have to re-write those portions. I am happy to try to track > everyone down but not without making sure Ron is receptive to this. > It was understood that we were doing work under the MIT license. It was open development for anyone's use. I set the license in the Cryptography repo. Rob > David > > |
|
|
Hello,
Here I am. Very nice to see some movement on cryptography. Let me know if there is something I can do to help. Rob it is very nice to hear from you. I hope you are doing well. Please feel free to run with the Cryptography Team if you have time. I'll try to pay a bit more attention. All the best, Ron Teitelbaum > -----Original Message----- > From: Rob Withers [mailto:[hidden email]] > Sent: Wednesday, June 30, 2010 2:10 PM > To: The general-purpose Squeak developers list; Ron Teitelbaum; Squeak > Cryptography > Subject: Re: [squeak-dev] Re: Cryptography > > -------------------------------------------------- > From: "C. David Shaffer" <[hidden email]> > Sent: Wednesday, June 30, 2010 12:11 PM > To: "The general-purpose Squeak developers list" > <[hidden email]>; "Ron Teitelbaum" > <[hidden email]>; "Squeak Cryptography" > <[hidden email]> > Subject: [squeak-dev] Re: Cryptography > > > On 06/29/10 22:36, Rob Withers wrote: > >> Hi David, > >> > >> I am CCing the squeak-dev list. > >> > >> I had tried to contact Ron over the weekend, since he is the admin for > >> the SqueakSource Cryptography package. I needed to add you as a > >> member of the Crypto team. That's right, you are a member now. I > >> didn't hear from him so the email address may be bad. We'll see if > >> we hear from him in the future. I hope so. > >> > >> Do you have the link to the Crypto mailing list? > > Yes, do we move this discussion there? > > We can discuss in one or both. Your choice. I think the most visibility > will be from discussing it on squeak-dev. > > > > >> > >> I agree we should do this in public. I would suggest the squeak-dev > >> list. > >> > >> We may have several "forks" and/or subsequent work done from the root > >> package. > >> > >> The root package for SSL is in the Monticello repository > >> http://www.squeaksource.com/Cryptography, but it may not be the > >> latest. I think that the SSL package there is the latest...Whoa! I > >> just checked again and new SSL packages were inserted 2 days ago. The > >> latest there used to be SSL-rww.4.mcz and now there is a SSL- > jrd.12.mcz. > > > > Yes, I copied the mods from the croquet-source repo. SSL was easy as > > there were no forks. jrd.12 is the version I am using and it is working > > pretty well. I did have some intermittent failures when I was first > > moving to Squeak4.1 but those might have been due to errant versions of > > the Cryptography package. I will do a fresh build and verify this > > version. > > > > Ah, excellent. I also have SSL-jrd.12.mcz loaded. > > I have one class in SSL that I use in SqueakElib. When I load both, it > rips > it from one location and places it in another (different categories). > Stéphane Ducasse has pointed me to metacello > (http://gemstonesoup.wordpress.com/2009/08/25/metacello-package- > management-for-monticello/), > which is a package management system. It allows one to load dependent > packages. You might want to look into it. > > >> > >> The root package for Cryptography is in the same repository, but it is > >> less clear which is the latest and greatest. There is a mixture of > >> version numbers. I am using Cryptography-cmm.13.mcz. All tests pass > >> except for a Rindael test and an X509 test (due to bad validity dates). > >> > >> I know there is packages in > >> http://croquet-src-01.oit.duke.edu:8886/Contributions. SSL look like > >> the ones now in the Cryptography repository above. The Cryptography > >> packages in Contributions look like they are also in the Cryptography > >> repository, but mixed up with other work. In Contributions, there is > >> the sequence of packages: > >> > >> Cryptography-RJT.10.mcz (the root package) > >> Cryptography-jrd.11.mcz > >> Cryptography-jrd.12.mcz > >> Cryptography-mtf.13.mcz > >> > >> These are interwoven with other packages in the Cryptography > >> repository, with the same version numbers. > > > > Right, there are several forks to be reconciled. FWIW I am running > > mtf.13 as none of the versions from the original Cryptography repo had > > ASN.1 support needed to do SSL (SSL30 or TLS10/11). Unfortunately this > > version fails CryptoX509Test>>testSignatureValidation (as well as the > > Rindael test you mentioned). I am hoping the harvesting from the other > > forks will take care of this. > > I need to fix the X509 error. > > > > > At this point all of the croquet-source versions are in their rightful > > place in the Cryptography project on SqueakSource. The SqueakSource > > project contains no license information. It would be a very good idea > > to assign a license so that all contributions to this repo are > > automatically assigned that license. I think Ron needs to guide this > > process as this is his baby. At the very least Ron and all other > > contributors need to be asked to accept whatever license is selected or > > we will have to re-write those portions. I am happy to try to track > > everyone down but not without making sure Ron is receptive to this. > > > > It was understood that we were doing work under the MIT license. It was > open development for anyone's use. I set the license in the Cryptography > repo. > > Rob > > > David > > > > |
|
|
On 07/01/10 19:37, Ron Teitelbaum wrote:
> Hello, > > Here I am. Very nice to see some movement on cryptography. Let me know if > there is something I can do to help. > > I've merged all of the forks, I think. I do have a couple questions but I'll come back to those later. Rob suggested creating a Metacello configuration for people to use to load things. That is priority #2 for me...right after the merge. David |
|
|
I'm calling Cryptography-rww.16 the "trunk" version. The only branch
that has changes that aren't in the trunk looks like the "cmm" branch. Below is a summary of the change logs from that branch. It started from RJT.6 and moved linearly to cmm.13. Among these changes are: 1) cmm.12 which fixed an Undelcared var and needs to be applied to the trunk 2) cmm.11 which drops extensions to ThirtyTwoBitRegister which were absorbed in Squeak3.11 and are also present in 4.1. Do we want to continue to include them in Cryptography package? My suggestion is to move them from Cryptography to CryptoThirtyTwoBitRegisterExtensions which will only be loaded in pre-Squeak3.11 images. I don't know anything about Metacello yet but maybe we can make it smart enough to load these in older images. 3) cmm.8 contains #destroy in ElGamalKeyGenerator and String which are not in trunk. The only user of the former is DiffieHellman which provides no path to send destroy to the generator unless it is sent by a third party (df generator destroy). Methods are untested. 4) cmm.9 which adds a species check in ASN1Object>>=. This change is not in the trunk but there are no tests that fail as a result of its absence. Chris: do you remember your motivation for adding this? For now I'll fix "1" and await feedback on others. David Summary of cmm branch changes: cmm.7 changes: ****not in trunk - Added ElGamalKeyGenerator>>#destroy to clean-up in-memory secrets. - Removed faulty optimization of Fortuna>>#nextInt:. Now inherits slower but correct one from superclass. cmm.8 changes: ****not in trunk - Added String>>#destroy and HashFunction class>>#doubleHashMessage:. cmm.9 changes: ****not in trunk - Fix for ASN1Object>>#=. cmm.10 changes: **** fixed in trunk - Fixed syntax error in SHA1>>#hashInteger:seed:. cmm.11 changes: **** not in trunk - For Squeak 3.11. Removed methods from ThirtyTwoBitRegister which 3.11 absorbed. This allows this package to load into 3.11 without causing a dirty System package. cmm.12 changes: **** not in trunk --- NEEDS TO BE DONE IN TRUNK - Removed methods referring to old 'Picker' classVar. It was changed to a class-inst var. Note: class-inst var is in RandomGenerator cmm.13 changes: At least partially in trunk. Too many changes to verify but most seem to have been converted in trunk. - FixUnderscores |
|
|
Thanks for taking care of this David. Comments inlined:
> 2) cmm.11 which drops extensions to ThirtyTwoBitRegister which were > absorbed in Squeak3.11 and are also present in 4.1. Do we want to > continue to include them in Cryptography package? My suggestion is to > move them from Cryptography to CryptoThirtyTwoBitRegisterExtensions > which will only be loaded in pre-Squeak3.11 images. I don't know > anything about Metacello yet but maybe we can make it smart enough to > load these in older images. Well, legacy apps still using 3.9 probably don't want to upgrade to the latest Cryptography before upgrading to Pharo or Squeak 4.1+.. I've read about Metacello, but not yet taken the time to get deeply into it. My sense is that we don't need it to solve this issue. Simply a more generic package for the purpose of backward compatibility, i.e., a "Crypto3.9Compatibility" package, could house these extnesions? Still, I'd bet if you just merged my version, the removal of these extensions from Crypto, and do nothing else, there will be no complaints. > 3) cmm.8 contains #destroy in ElGamalKeyGenerator and String which are > not in trunk. The only user of the former is DiffieHellman which > provides no path to send destroy to the generator unless it is sent by a > third party (df generator destroy). Methods are untested. Please include these important changes. ElGamalKeyGenerator is used directly by *clients*, who call #destroy. After generating a ElGamal key pair and safely encrypting and saving it, it is important to then destroy the generator so that its sensitive numbers aren't accidently left hanging around in the image..! These changes are essential, they should be merged. DiffieHellman uses ElGamalKeyGenerator for a different purpose (authentication).. > 4) cmm.9 which adds a species check in ASN1Object>>=. This change is > not in the trunk but there are no tests that fail as a result of its > absence. Chris: do you remember your motivation for adding this? Yes, of course, very bad breakage. Any class implementing #= must allow for the possibility that the comparand will not be of the same type. Virtually every #= implementation in the system does this. A simple test: self deny: (ASN1ObjectId fromString: '1.3.6.1.5.5.7.8.5') = Object new fails. > For now I'll fix "1" and await feedback on others. Thanks again, Chris |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |