Fwd: Include Cryptographic Primitives In VM's - DESPlugin

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: Include Cryptographic Primitives In VM's - DESPlugin

Adrian Lienhard

Begin forwarded message:

> 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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Include Cryptographic Primitives In VM's - DESPlugin

timrowledge
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.



Reply | Threaded
Open this post in threaded view
|

RE: Fwd: Include Cryptographic Primitives In VM's - DESPlugin

Ron Teitelbaum
Thank you!  (and test to vm list)

Ron

> -----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.
>
>



Reply | Threaded
Open this post in threaded view
|

VMMaker organzation (was: Re: Fwd: Include Cryptographic Primitives In VM's - DESPlugin)

Andreas.Raab
In reply to this post by timrowledge
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.
>
>
>

Reply | Threaded
Open this post in threaded view
|

RE: VMMaker organzation (was: Re: Fwd: Include CryptographicPrimitives In VM's - DESPlugin)

Ron Teitelbaum
+1 from n00b (so I don't really count).

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)

Thanks,
Ron

> -----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.
> >
> >
> >



Reply | Threaded
Open this post in threaded view
|

Re: VMMaker organzation (was: Re: Fwd: Include Cryptographic Primitives In VM's - DESPlugin)

Bert Freudenberg
In reply to this post by Andreas.Raab
Am 17.10.2006 um 00:39 schrieb Andreas Raab:

> 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?

I got it! I like it! :)

One nit - why don't call it VM-* ? "Maker" is so ... (looking for one  
of Tim's terrifically magniloquent terms)

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: VMMaker organzation (was: Re: Fwd: Include CryptographicPrimitives In VM's - DESPlugin)

Andreas.Raab
In reply to this post by Ron Teitelbaum
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

Reply | Threaded
Open this post in threaded view
|

RE: VMMaker organzation (was: Re: Fwd:Include CryptographicPrimitives In VM's - DESPlugin)

Ron Teitelbaum
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 think we are fine for a temp solution and can handle most sophisticated
users as is, but for a long term solution I was hoping to have the VM
include it.  No rush especially since we have more to add.  Good luck with
debugging the problem.  

Maybe after reading Dave's docs I'll even understand what cc1 is!  When all
else fails check your compiler options!

Thanks again,
Ron

> -----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



Reply | Threaded
Open this post in threaded view
|

Re: VMMaker organzation (was: Re: Fwd:Include CryptographicPrimitives In VM's - DESPlugin)

timrowledge
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



Reply | Threaded
Open this post in threaded view
|

Re: VMMaker organzation (was: Re: Fwd: Include Cryptographic Primitives In VM's - DESPlugin)

timrowledge
In reply to this post by Andreas.Raab
Ok, so I've started a VMMaker repository in SqueakSource ready to  
fill with stuff.

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?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- If brains were taxed, he'd get a rebate.



Reply | Threaded
Open this post in threaded view
|

Re: VMMaker organzation

Andreas.Raab
Hi Tim -

tim Rowledge wrote:
> Ok, so I've started a VMMaker repository in SqueakSource ready to fill
> with stuff.

Can we set one up on source.sqf.org? Squeaksource.com has been pretty
unreliable for me.

> 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).

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

RE: VMMaker organzation (was: Re: Fwd:Include CryptographicPrimitives In VM's - DESPlugin)

Ron Teitelbaum
In reply to this post by timrowledge
Tim,

I know we've discussed this already.  The code will work both internally and
externally now, but there are still concerns and I still believe that this
is one set of code that needs to be internal and not external.  

The first concern is security.  My concern is communication between the VM
and the dll.  I won't pretend to be and expert on the dll load and memory
handling but simple is definitely better.

The second concern is packaging.  One of the requirements of cryptographic
validation is isolation.  We need to find a way to isolate our code and
guarantee that it is run unmodified.  Having a single file to protect is a
definite advantage, especially if part of our solution is a signed VM.

I think I understand the point you are trying to make, and still believe
that internal is better and eventually it may be mandatory.

Thanks,
Ron

> -----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
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Re: VMMaker organzation

Bert Freudenberg
In reply to this post by Andreas.Raab
Am 17.10.2006 um 02:55 schrieb Andreas Raab:

> Hi Tim -
>
> tim Rowledge wrote:
>> Ok, so I've started a VMMaker repository in SqueakSource ready to  
>> fill with stuff.
>
> Can we set one up on source.sqf.org? Squeaksource.com has been  
> pretty unreliable for me.

Repeating myself, but *please* can we name it "vm"?

>> 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).

I'd go for one MC package per plugin. If I were to start toying with  
a new plugin I'd put it into a separate package. In fact, that's what  
I did a couple of times. When the plugin gets ready for inclusion in  
the official repository, nothing would have to change, history is  
preserved etc.

vm-maker (building, UI)
vm-translation (translator) ... might also be called "slang" to give  
noobs an a-ha
vm-core (Interpreter, ObjectMemory)
vm-io-socket
vm-io-async
vm-sound-midi
vm-graphics-bitblt

What would be the downside downside of doing this? I see none really.

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: Re: VMMaker organzation

David T. Lewis
On Tue, Oct 17, 2006 at 01:40:15PM +0200, Bert Freudenberg wrote:
>
> vm-maker (building, UI)
> vm-translation (translator) ... might also be called "slang" to give  
> noobs an a-ha
> vm-core (Interpreter, ObjectMemory)
> vm-io-socket
> vm-io-async
> vm-sound-midi
> vm-graphics-bitblt

This looks like about the right level of organization, and it is
certainly a good idea to separate the building tools from the actual
VM and plugins.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Re: VMMaker organzation

timrowledge
In reply to this post by Andreas.Raab

On 16-Oct-06, at 5:55 PM, Andreas Raab wrote:

> Hi Tim -
>
> tim Rowledge wrote:
>> Ok, so I've started a VMMaker repository in SqueakSource ready to  
>> fill with stuff.
>
> Can we set one up on source.sqf.org? Squeaksource.com has been  
> pretty unreliable for me.

Fair enough; I've emailed the admin (since I can't just make a  
project) and will await action.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: ESBD: Erase System and Burn Documentation



Reply | Threaded
Open this post in threaded view
|

Re: Re: VMMaker organzation

Bryce Kampjes
In reply to this post by Bert Freudenberg
Bert Freudenberg writes:
 > I'd go for one MC package per plugin. If I were to start toying with  
 > a new plugin I'd put it into a separate package. In fact, that's what  
 > I did a couple of times. When the plugin gets ready for inclusion in  
 > the official repository, nothing would have to change, history is  
 > preserved etc.

I'd go for a total of one MC package for everything just as we have
now. It makes it easier to load, to share, to branch, and to keep in
sync. With a single package it's impossible to end up with versioning
problems between sub-packages. I know that there are MCC thingies that
should help when loading from a Monticello repository, but how easy
are they to bundle for SqueakMap or merge, or fork in a private
repository?

To increase decentralization, why not just give Andreas and Rob write
access to a central publically readable repository? If Rob only needs
access for Crypto, then let's just trust him not to abuse commit
privileges. If commit privileges are abused then they can be removed
and all changes will be under version control so should be able to be
undone.  Giving out write privileges would also allow people other
than Tim to commit (harvest) obvious fixes. Tim can always be required
to inspect any release then bless it before writing the commit
message.

The biggest problem people strike when starting to help out on Exupery
is assembling a VM build environment. Splitting VMMaker into separate
projects will make this harder as Exupery has it's own VMMaker branch.
With a single MC package this is easy to deal with. A single package
makes it easier for people to maintain experimental branches outside
of the mainstream VM.

VMMaker is still small enough to email comfortably. The only good
reasons I can see to split it is if people want to mix and match
versions of new packages or not install the entire thing. Neither
seems probable especially as plugins can already be built separately.

Bryce