Cryptography July 2010

cryptography@lists.squeakfoundation.org

5 participants
12 discussions

DESPlugin is broken
by Rob Withers 25 Jul '10

25 Jul '10

Hans-Martin Mosner, if you have your ears on, I could use some help figuring out the algorithm. Anyone else for that matter. Here is the spec: http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf The key is cooked for encryption or decryption The data block is submitted for encryption (or decryption, depending on the cooked key) - first the data block is permuted using the Initial Permutation - result of the permutation step is encrypted using the cooked key - result of the encryption step is permuted using the inverse of the Initial Permutation I do not know if the problem is with the key cooking or the encryption transformation. Thanks for any help! Rob

2 3

RE: [squeak-dev] Re: [Vm-dev] Cryptography in the main image andPlugins build for the VMs
by Ron Teitelbaum 10 Jul '10

10 Jul '10

Hi All, As a reminder we did register to allow US developers to contribute and for anyone to download the code from SqueakSource (and google). http://lists.squeakfoundation.org/pipermail/cryptography/2006-January/000121 .html What this does not do is allow users to download the main image from anywhere else. http://forum.world.st/UPDATE-Notification-of-publicly-available-cryptography -code-td133064.html If we decide to make the code available in the main image then there are two things to consider. First it needs to be registered. Second it could make distributing Squeak more difficult for end users of Squeak in the United States that want to send the code outside the US. Downloading the code from these locations from anywhere is allowed but downloading packaging and sending your final product somewhere is not covered. I am not a lawyer so please get proper legal advice before exporting any cryptographic code. All the best, Ron Teitelbaum Teleplace > -----Original Message----- > From: squeak-dev-bounces(a)lists.squeakfoundation.org [mailto:squeak-dev- > bounces(a)lists.squeakfoundation.org] On Behalf Of Miguel Enrique Cobá > Martínez > Sent: Friday, July 09, 2010 11:10 AM > To: The general-purpose Squeak developers list > Cc: Squeak Crypto; Squeak Virtual Machine Development Discussion > Subject: Re: [squeak-dev] Re: [Vm-dev] Cryptography in the main image > andPlugins build for the VMs > > El jue, 08-07-2010 a las 16:50 -0700, Steve Wart escribió: > > Given that cryptography still faces export restrictions, would this > > cause problems for OSS distributions that want to include Squeak? > > This is not true. Every linux distro comes with strong security. Nobody > cares about export restrictions. I have downloaded from kernel.org that > is located in USA. No problem. > > But if that is your concern, then you only need to put the cryptography > package in a server outside the USA (Europe would be fine) and problem > solved. > > But, that export restrictions are a problem that was solved a decade > ago. > > Cheers > > > > Also I'm not sure that people who want to minimize their image size > > would benefit. Why can't Cryptography be easily loaded by people who > > need it? > > > > Steve > > > > On Thu, Jul 8, 2010 at 2:07 AM, Rob Withers <reefedjib(a)yahoo.com> wrote: > > > > > > Hi all, > > > > > > I would like to propose that Cryptography be included as part of the > image, > > > by default. As it stands now it is in the Cryptography repository, > which > > > most don't seem to know about or there are one-off copies that are > developed > > > separately. David Shaffer has been stewarding a reintegration of > these > > > forks and ensuring the tests pass. Everyone should be able to take > > > advantage of the algorithms provided by the Cryptography package. > > > > > > Along the same lines, it would be a great help for the vm providers to > > > include the CryptographyPlugins when they build a new vm. I believe > there > > > are 3 plugins and they really ought to be build internally, since they > are > > > unchanging. > > > > > > I would like to hear what others think of the possibility of making > this > > > change. > > > > > > Thank you, > > > Rob > > > > > > > > > > > > > -- > Miguel Cobá > http://miguel.leugim.com.mx >

1 0

Cryptography: plugins
by C. David Shaffer 10 Jul '10

10 Jul '10

The Cryptography package (at one point) contained the following classes which extend "plugin" related classes which are not part of the typical squeak image btw, typical = used by me :-) DESPlugin (subclass of InterpreterPlugin) DSAPlugin (subclass of InterpreterPlugin) MD5Plugin (subclass of SmartSyntaxInterpreterPlugin) These seem to have been dropped from various forks and the trunk probably because the publisher (including me) did not have the appropriate superclasses loaded when we loaded Cryptography. The latest versions were available in mtf.13. So: 1) Are these plugins to be maintained as part of Cryptography? or somewhere else? 2) If "yes" to 1, can I move them to a separate Monticello package? David

4 4

Re: [squeak-dev] Re: [Vm-dev] Cryptography in the main image and Plugins build for theVMs
by Rob Withers 09 Jul '10

09 Jul '10

Casey, This works for me. As long as Crypto is visible and easily loadable I think the requirements are met. Any idea when this "community supported packages" will become a reality? Cheers, Rob From: Casey Ransberger Sent: Thursday, July 08, 2010 10:11 PM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] Re: [Vm-dev] Cryptography in the main image and Plugins build for theVMs There is a plan that solves this problem using Monticello configurations. We're calling them community supported packages. More info here: http://comments.gmane.org/gmane.comp.lang.smalltalk.squeak.general/148414 Basically, you can keep your bits shipping as automatically loadable from Squeak where version and dependency information is preserved. It's pretty sweet:) On Thu, Jul 8, 2010 at 7:00 PM, Rob Withers <reefedjib(a)yahoo.com> wrote: -------------------------------------------------- From: "Steve Wart" <steve(a)wart.ca> Sent: Thursday, July 08, 2010 7:50 PM To: "Squeak Virtual Machine Development Discussion" <vm-dev(a)lists.squeakfoundation.org> Cc: "Squeak Crypto" <cryptography(a)lists.squeakfoundation.org>; "Squeak Dev" <squeak-dev(a)lists.squeakfoundation.org> Subject: Re: [Vm-dev] Cryptography in the main image and Plugins build for theVMs Given that cryptography still faces export restrictions, would this cause problems for OSS distributions that want to include Squeak? I am not familiar with which pieces of Cryptography are export restricted and which are not. According to the Java SDK Crypto docs (http://download.oracle.com/docs/cd/E17476_01/javase/1.4.2/docs/guide/securi…) DSA, MD5 and SHA-1 are at least distributable. This obviously reduces the attractiveness of including Crypto in the image, were we to have to split the package into exportable and non-exportable packages. Also I'm not sure that people who want to minimize their image size would benefit. Why can't Cryptography be easily loaded by people who need it? People may not know where it resides. It is not a part of the trunk. It is in a SqueakSource repository. Thanks, Rob Steve On Thu, Jul 8, 2010 at 2:07 AM, Rob Withers <reefedjib(a)yahoo.com> wrote: Hi all, I would like to propose that Cryptography be included as part of the image, by default. As it stands now it is in the Cryptography repository, which most don't seem to know about or there are one-off copies that are developed separately. David Shaffer has been stewarding a reintegration of these forks and ensuring the tests pass. Everyone should be able to take advantage of the algorithms provided by the Cryptography package. Along the same lines, it would be a great help for the vm providers to include the CryptographyPlugins when they build a new vm. I believe there are 3 plugins and they really ought to be build internally, since they are unchanging. I would like to hear what others think of the possibility of making this change. Thank you, Rob -- Casey Ransberger --------------------------------------------------------------------------------

1 0

Re: [Vm-dev] Cryptography in the main image and Plugins build for theVMs
by Rob Withers 09 Jul '10

09 Jul '10

-------------------------------------------------- From: "David T. Lewis" <lewis(a)mail.msen.com> Sent: Thursday, July 08, 2010 10:26 PM To: "Squeak Virtual Machine Development Discussion" <vm-dev(a)lists.squeakfoundation.org> Cc: "Squeak Crypto" <cryptography(a)lists.squeakfoundation.org>; "Squeak Dev" <squeak-dev(a)lists.squeakfoundation.org> Subject: Re: [Vm-dev] Cryptography in the main image and Plugins build for theVMs > > On Thu, Jul 08, 2010 at 05:07:29AM -0400, Rob Withers wrote: > > <snip> > >> Along the same lines, it would be a great help for the vm providers to >> include the CryptographyPlugins when they build a new vm. I believe >> there >> are 3 plugins and they really ought to be build internally, since they >> are >> unchanging. > > Hi Rob, > > With respect to the plugins (and I know this was discussed in earlier > emails) can you please provide a link to the SqueakSource repository for > the three plugins? We can add this to the VMMaker configuration map and > to ConfigurationOfVMMaker so they will be easily loaded into VM > development > images. > > Assuming no legal issues, I would expect that the plugins can be included > in future VM builds without difficulty (at the discretion of the platform > maintainers of course). BTW, don't worry about internal versus external, > that's a packaging issue, and if there is any concern about legal issues > (real or imagined) it will probably be best to make them external modules > for the benefit of folks who may be concerned about such things. > > Thanks, > Dave Hi Dave, Thanks, this would be great! The repository containing the Crypto plugins is: MCHttpRepository location: 'http://www.squeaksource.com/Cryptography' user: '' password: '' The package is CryptographyPlugins, newly created. There are 4 plugins: DESPlugin, DSAPlugin, MD5Plugin, and SHA256Plugin. Under the relaxation in export restrictions in 2000, all of these are exportable. Thanks, Rob >

1 0

Re: [Vm-dev] Cryptography in the main image and Plugins build for theVMs
by Rob Withers 09 Jul '10

09 Jul '10

-------------------------------------------------- From: "Steve Wart" <steve(a)wart.ca> Sent: Thursday, July 08, 2010 7:50 PM To: "Squeak Virtual Machine Development Discussion" <vm-dev(a)lists.squeakfoundation.org> Cc: "Squeak Crypto" <cryptography(a)lists.squeakfoundation.org>; "Squeak Dev" <squeak-dev(a)lists.squeakfoundation.org> Subject: Re: [Vm-dev] Cryptography in the main image and Plugins build for theVMs > > Given that cryptography still faces export restrictions, would this > cause problems for OSS distributions that want to include Squeak? > I am not familiar with which pieces of Cryptography are export restricted and which are not. According to the Java SDK Crypto docs (http://download.oracle.com/docs/cd/E17476_01/javase/1.4.2/docs/guide/securi…) DSA, MD5 and SHA-1 are at least distributable. This obviously reduces the attractiveness of including Crypto in the image, were we to have to split the package into exportable and non-exportable packages. > Also I'm not sure that people who want to minimize their image size > would benefit. Why can't Cryptography be easily loaded by people who > need it? People may not know where it resides. It is not a part of the trunk. It is in a SqueakSource repository. Thanks, Rob > > Steve > > On Thu, Jul 8, 2010 at 2:07 AM, Rob Withers <reefedjib(a)yahoo.com> wrote: >> >> Hi all, >> >> I would like to propose that Cryptography be included as part of the >> image, >> by default. As it stands now it is in the Cryptography repository, which >> most don't seem to know about or there are one-off copies that are >> developed >> separately. David Shaffer has been stewarding a reintegration of these >> forks and ensuring the tests pass. Everyone should be able to take >> advantage of the algorithms provided by the Cryptography package. >> >> Along the same lines, it would be a great help for the vm providers to >> include the CryptographyPlugins when they build a new vm. I believe >> there >> are 3 plugins and they really ought to be build internally, since they >> are >> unchanging. >> >> I would like to hear what others think of the possibility of making this >> change. >> >> Thank you, >> Rob >> >> >>

1 0

Cryptography in the main image and Plugins build for the VMs
by Rob Withers 08 Jul '10

08 Jul '10

Hi all, I would like to propose that Cryptography be included as part of the image, by default. As it stands now it is in the Cryptography repository, which most don't seem to know about or there are one-off copies that are developed separately. David Shaffer has been stewarding a reintegration of these forks and ensuring the tests pass. Everyone should be able to take advantage of the algorithms provided by the Cryptography package. Along the same lines, it would be a great help for the vm providers to include the CryptographyPlugins when they build a new vm. I believe there are 3 plugins and they really ought to be build internally, since they are unchanging. I would like to hear what others think of the possibility of making this change. Thank you, Rob

1 0

Re: [squeak-dev] Cryptography: Fortuna>>nextInt:
by Chris Muller 06 Jul '10

06 Jul '10

(Copying to the Crypto list, should we move discussion over there altogether?) Random Fortuna is a random-stream-of-bytes generator, no Floats are involved to overflow. However, I do see, now, why I tried to override nextInt: in Fortuna: performance. The inherited implementation from SecureRandom: nextInt: anInteger "Answer a random integer in the interval [1, anInteger]." | r high | anInteger strictlyPositive ifFalse: [ self error: 'Range must be positive' ]. high := anInteger-1. [ (r := self nextBits: anInteger highBit) between: 0 and: high ] whileFalse. ^ r+1 So it may have do a little churning before it arrives at something in-range. Surely there is a less-wasteful way to do it. Fortuna tried, but failed. How can a random-stream-of-bytes generator be used for a faster #nextInt:? BTW, it looks like the #nextInt: implementation in SecureRandom is an exact duplicate of its superclass impl.. probably can be removed. - Chris On Tue, Jul 6, 2010 at 11:05 AM, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: > Having dealt with rather large encryption keys (2048 bit) here's the fix > we've had for Random>>nextInt: > > nextInt: anInteger > "Answer a random integer in the interval [1, anInteger]. > Handle large numbers too (for cryptography)." > > anInteger strictlyPositive ifFalse: [ self error: 'Range must be positive' > ]. > anInteger asFloat isInfinite > ifTrue: [^(self next asFraction * anInteger) truncated + 1]. > ^ (self next * anInteger) truncated + 1 > > Regards, Gary > > ----- Original Message ----- From: "Chris Muller" <asqueaker(a)gmail.com> > To: "The general-purpose Squeak developers list" > <squeak-dev(a)lists.squeakfoundation.org> > Cc: "Squeak Cryptography" <cryptography(a)lists.squeakfoundation.org> > Sent: Tuesday, July 06, 2010 4:52 PM > Subject: Re: [squeak-dev] Cryptography: Fortuna>>nextInt: > > > Hi David, yes, absolutely, Fortuna>>#nextInt: should be deleted, > because it is a flawed implementation, as the following script > demonstrates: > > "explore it" > |f| > f:=Fortuna picker. > ((1 to: 1000) collect: [ : n | f nextInt: 6 ]) asBag sortedCounts > > Note the consistent, heavy weighting for "1".. > > The method should be deleted so it can inherit the generic one in the > superclass. > > Thanks and Regards, > Chris > > > On Mon, Jul 5, 2010 at 2:58 PM, C. David Shaffer <cdshaffer(a)acm.org> wrote: >> >> I missed a method in my merge of Chris' branch: >> >> Fortuna>>nextInt: was removed by cmm.7 with the comment: >> >> "Removed faulty optimization of Fortuna>>#nextInt:. Now inherits slower >> but correct one from superclass." >> >> Chris: It looks like the original version has persistent (with >> underscores fixed) in the latest version. Can you confirm that I should >> remove the version below? >> >> Feedback from others? >> >> Thanks! >> >> David >> >> >> >> Fortuna>>nextInt: anInteger >> "Answer a random integer in the interval [1, anInteger]." >> | r high bits highestMultiple | >> anInteger strictlyPositive ifFalse: [ self error: 'Range must be positive' >> ]. >> high := anInteger-1. >> bits := high highBit. >> "Calculate highestMultiple of anInteger, so that we can simply divide r by >> anInteger and use the remainder for the random value." >> highestMultiple := (1 bitShift: bits) truncateTo: anInteger. >> [ (r := self nextBits: bits) >> between: 0 >> and: highestMultiple ] whileFalse. >> ^ r\\anInteger+1 >> >> >> > > >

1 0

Re: [squeak-dev] Cryptography: Fortuna>>nextInt:
by C. David Shaffer 06 Jul '10

06 Jul '10

On 07/06/10 12:05, Gary Chambers wrote: > Having dealt with rather large encryption keys (2048 bit) here's the > fix we've had for Random>>nextInt: > > nextInt: anInteger > "Answer a random integer in the interval [1, anInteger]. > Handle large numbers too (for cryptography)." > > anInteger strictlyPositive ifFalse: [ self error: 'Range must be > positive' ]. > anInteger asFloat isInfinite > ifTrue: [^(self next asFraction * anInteger) truncated + 1]. > ^ (self next * anInteger) truncated + 1 > > Regards, Gary > This looks like a proposed patch to the base image's Random. Cryptography doesn't use this random generator. Maybe this should be added to the source.squeak.org inbox? David

1 0

Cryptography: Fortuna>>nextInt:
by C. David Shaffer 06 Jul '10

06 Jul '10

I missed a method in my merge of Chris' branch: Fortuna>>nextInt: was removed by cmm.7 with the comment: "Removed faulty optimization of Fortuna>>#nextInt:. Now inherits slower but correct one from superclass." Chris: It looks like the original version has persistent (with underscores fixed) in the latest version. Can you confirm that I should remove the version below? Feedback from others? Thanks! David Fortuna>>nextInt: anInteger "Answer a random integer in the interval [1, anInteger]." | r high bits highestMultiple | anInteger strictlyPositive ifFalse: [ self error: 'Range must be positive' ]. high := anInteger-1. bits := high highBit. "Calculate highestMultiple of anInteger, so that we can simply divide r by anInteger and use the remainder for the random value." highestMultiple := (1 bitShift: bits) truncateTo: anInteger. [ (r := self nextBits: bits) between: 0 and: highestMultiple ] whileFalse. ^ r\\anInteger+1

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Cryptography July 2010