Fwd: Include Cryptographic Primitives In VM's - DESPlugin

> From: "Ron Teitelbaum" <[hidden email]>
> Date: October 16, 2006 9:24:00 PM GMT+02:00
> To: "'Adrian Lienhard'" <[hidden email]>
> Subject: FW: Include Cryptographic Primitives In VM's - DESPlugin
> Reply-To: <[hidden email]>
>
> Adrian,
>
> Could you forward this for me to vm-dev, I tried but it was  
> rejected.  I signed up again but didn’t get a response from mailman.
>
>
>
> All,
>
> When I originally sent this email I believed that DESPlugin was  
> part of VMMaker, I was wrong.  I uploaded two files to mantis one  
> that is incorrect but I couldn’t delete it, and a correct version  
> which should be considered the notes should make it clear.
>
> Please let me know if you need anything else, or have any  
> questions.  Thanks for your help!
>
> Ron Teitelbaum
>
>
>
> From: Ron Teitelbaum [mailto:[hidden email]]
> Sent: Thursday, October 12, 2006 9:52 AM
> To: '[hidden email]'; 'Cryptography Team  
> Development List'
> Subject: Include Cryptographic Primitives In VM's - DESPlugin
>
> http://bugs.impara.de/view.php?id=5228 :
>
> Hans-Martin did some testing and as we expected the performance of  
> pure squeak cryptography is disappointing:
>
> Hans-Martin wrote:
>
> "Ok, I did some measurements. Results are pretty disappointing.
>
> Squeak on my AMD 3800+ processor encrypts 32 KBytes using 3DES CBC  
> mode in about 8 seconds - unusable for anything but a proof-of-
> concept.
>
> Therefore I think that DES (and maybe some other small cryptographic
>
> primitives) should be part of the base VM."
>
>
>
> The DESPlugin is already a part of the VMMaker, I am asking the VM  
> group to please include the DESPlugin in the base VM that is  
> distrubuted.  We will be submitting more code and will follow the  
> process of code -> VMMaker -> VM.  If the VM team wants to wait  
> before building a new VM's until other primitives are available,  
> that is fine, but if a build is going to be done anyway for other  
> issues, please include the DESPlugin.
>
>
>
> Thank you for your help!
>
> Ron Teitelbaum
>
> Cryptography Team Leader
>
>

> -----Original Message-----
> From: [hidden email] [mailto:vm-dev-
> [hidden email]] On Behalf Of tim Rowledge
> Sent: Monday, October 16, 2006 4:30 PM
> To: Squeak Virtual Machine Development Discussion
> Subject: Re: [Vm-dev] Fwd: Include Cryptographic Primitives In VM's -
> DESPlugin
>
>
> I'll add DESPlugin to the next release of VMMaker and you can then
> persuade the vm makers to make sure it is included for testing.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Great leaders inspire by example. When that's not an option, brute
> intimidation works pretty well.
>
>

>
> I'll add DESPlugin to the next release of VMMaker and you can then
> persuade the vm makers to make sure it is included for testing.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Great leaders inspire by example. When that's not an option, brute
> intimidation works pretty well.
>
>
>

> -----Original Message-----
> From: [hidden email] [mailto:vm-dev-
> [hidden email]] On Behalf Of Andreas Raab
> Sent: Monday, October 16, 2006 6:40 PM
> To: Squeak Virtual Machine Development Discussion
> Subject: VMMaker organzation (was: Re: [Vm-dev] Fwd: Include
> CryptographicPrimitives In VM's - DESPlugin)
>
>
> Hi Tim and all -
>
> I'm wondering if we shouldn't "decentralize" the development of VMMaker
> a little. Right now, it seems pretty awkward for someone developing a
> plugin to update that plugin in any reasonable way. For example, the
> current VMMaker release has a somewhat outdated CroquetPlugin which
> -while not horribly broken- fails a few important tests in replication
> (I only noticed that over the weekend btw). The current solution set
> consists of me sending something via email to you in the hope it'll end
> up in some future version of VMMaker. Whether it's gotten there or not I
> can't tell without actually looking at the code itself, e.g., there
> isn't an easy way for me to say "oh, no, Tim's forgotten to include the
> latest Croquet plugin for the 3.9 release! Where is the tar? Where are
> the feathers?" ;-)
>
> So here is a question: What if we organize a monticello repository with
> sub-packages for the individual plugins which then get updated by
> individuals maintaining these? What I'm thinking about is something like:
>
>    VMMaker-Generation (CCodeGen, VMMaker, UI)
>    VMMaker-Interpreter (ObjectMemory, Interpreter)
>    VMMaker-Crypto (all the crypto plugins)
>    VMMaker-Croquet (all the croquet related ones)
>
> etc. This would allow (say) Ron to update the crypto plugin
> independently from me updating the Croquet plugins and it wouldn't
> require you to be in the loop for every minor change. "Real" releases
> might be managed simply by posting a Monticello configuration that lists
> all the packages for that particular version of VMMaker (plus optional
> file releases through SM - I've used load scripts to good effect for
> that in the FFI and one could probably even write a translator that
> takes a configuration as input and spits out an SM loadscript).
>
> Does this make sense to anyone but me?
>
> Cheers,
>    - Andreas
>
>
> tim Rowledge wrote:
> >
> > I'll add DESPlugin to the next release of VMMaker and you can then
> > persuade the vm makers to make sure it is included for testing.
> >
> > tim
> > --
> > tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> > Great leaders inspire by example. When that's not an option, brute
> > intimidation works pretty well.
> >
> >
> >

> Hi Tim and all -
>
> I'm wondering if we shouldn't "decentralize" the development of  
> VMMaker a little. Right now, it seems pretty awkward for someone  
> developing a plugin to update that plugin in any reasonable way.  
> For example, the current VMMaker release has a somewhat outdated  
> CroquetPlugin which -while not horribly broken- fails a few  
> important tests in replication (I only noticed that over the  
> weekend btw). The current solution set consists of me sending  
> something via email to you in the hope it'll end up in some future  
> version of VMMaker. Whether it's gotten there or not I can't tell  
> without actually looking at the code itself, e.g., there isn't an  
> easy way for me to say "oh, no, Tim's forgotten to include the  
> latest Croquet plugin for the 3.9 release! Where is the tar? Where  
> are the feathers?" ;-)
>
> So here is a question: What if we organize a monticello repository  
> with sub-packages for the individual plugins which then get updated  
> by individuals maintaining these? What I'm thinking about is  
> something like:
>
>   VMMaker-Generation (CCodeGen, VMMaker, UI)
>   VMMaker-Interpreter (ObjectMemory, Interpreter)
>   VMMaker-Crypto (all the crypto plugins)
>   VMMaker-Croquet (all the croquet related ones)
>
> etc. This would allow (say) Ron to update the crypto plugin  
> independently from me updating the Croquet plugins and it wouldn't  
> require you to be in the loop for every minor change. "Real"  
> releases might be managed simply by posting a Monticello  
> configuration that lists all the packages for that particular  
> version of VMMaker (plus optional file releases through SM - I've  
> used load scripts to good effect for that in the FFI and one could  
> probably even write a translator that takes a configuration as  
> input and spits out an SM loadscript).
>
> Does this make sense to anyone but me?

> -----Original Message-----
> From: [hidden email] [mailto:vm-dev-
> [hidden email]] On Behalf Of Andreas Raab
> Sent: Monday, October 16, 2006 7:30 PM
> To: Squeak Virtual Machine Development Discussion
> Subject: Re: VMMaker organzation (was: Re: [Vm-dev] Fwd:Include
> CryptographicPrimitives In VM's - DESPlugin)
>
>
> Ron Teitelbaum wrote:
> > By the way what are the chances that those people that are currently
> > maintaining platform VMs will actually be building new VM's?  Is there a
> > schedule or process, or just random recompilation?  (I'm not asking that
> a
> > new vm be created since we have more plug-ins to contribute yet, I was
> just
> > wondering)
>
> It's pretty random depending on whether time allows playing around with
> stuff or not. Like, for me, I'm currently facing this stupid cc1 crash
> when I try to compile a VM and downgrading to a previous version to
> figure out what exactly went wrong where has proven to be an
> extraordinary pain in the rear end.
>
> If you want to update your plugin(s) on your own, you should get a build
> environment set up and build them externally (so people can use them as
> drop-in replacement).
>
> Cheers,
>    - Andreas

>
> Andreas,
>
> Yeah we can do that already but it's been a major pain in the pa-
> toody too!
> That's why we want to go with an internal vm code.  We lost one  
> platform
> plugin and had to make a new one, and now with the des smalltalk
> representation if the plugin is not there it still works, just  
> really badly
> (but good enough for testing).

> -----Original Message-----
> From: tim Rowledge [mailto:[hidden email]]
> Sent: Monday, October 16, 2006 7:59 PM
> To: [hidden email]; Squeak Virtual Machine Development Discussion
> Subject: Re: VMMaker organzation (was: Re: [Vm-dev] Fwd:Include
> CryptographicPrimitives In VM's - DESPlugin)
>
> Ron, I can't help thinking you're confused about something here.
> Internal or external makes no difference to the plugin. If you've
> written code that only works with it built and linked internal then
> you've written it wrong.
>
> The *only* particular value to making a plugin internal is that it
> simplifies distribution for unix & windows platforms by having a
> single executable.
>
> On 16-Oct-06, at 4:52 PM, Ron Teitelbaum wrote:
>
> >
> > Andreas,
> >
> > Yeah we can do that already but it's been a major pain in the pa-
> > toody too!
> > That's why we want to go with an internal vm code.  We lost one
> > platform
> > plugin and had to make a new one, and now with the des smalltalk
> > representation if the plugin is not there it still works, just
> > really badly
> > (but good enough for testing).
>
> I'm confused about "We lost one platform plugin" - can you expand on
> this?
>
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: RJT: Read and Jam Tape
>
>

>> How fine grained would people like the sub-packages to be? We  
>> could go bananas and have each plugin separate, the VMMaker &  
>> VMMakerTool, the interpreter class, the object memory etc all  
>> split out. Or it could be main vm code, vmmaker, core plugins,  
>> andreas' plgins, ron's plugins... etc.
>> Whaddya want?
>
> Something in the middle perhaps. Like I/O (socket, files, async  
> files), then graphics (bitblt, balloon, jpeg, bmp), sound (wave,  
> gsm, midi) etc. (I don't have a list of plugins on my finger tips  
> or else I would have made up a list from them).