Cryptography November 2006

cryptography@lists.squeakfoundation.org

8 participants
23 discussions

Developing in what image/version/build?
by Cerebus 03 Dec '06

03 Dec '06

With the plethora of Squeak images, versions, builds, whatever, I'm a little confused as to picking the best environment. Currently I've been working in the 3.9-8 VM with the 3.9-final-7067 image, but some things don't seem to work right. -- Tim

3 6

Re: [Cryptography Team] Developing in what image/version/build?
by Chris Muller 01 Dec '06

01 Dec '06

There's plenty about 3.9 that is less than acceptable. I've moved back to 3.8 my forward development until 3.9 improves. I recommend 3.8 for new Squeakers. 3.9 has some real usability issues that turn off new and old users alike; like lists jumping around upon selection is just one of many. 3.8 offers a cleaner start, less confusing, and you don't have Monticello packages with changes in the base image. The uninterruptable image lockups though, all on their own, were plenty enough for me to switch back. 3.9 has that new window look, but you can get that in 3.8 real easy if you want: http://map.squeak.org/package/3f07c64c-e22f-42ef-91e1-40c7e0de9185

2 1

RE: [Cryptography Team] Quick thoughton certification
by Ron Teitelbaum 28 Nov '06

28 Nov '06

It's a very good question. I'm hoping that the StrongTalk VM will indeed blossom and become a powerful force in Open Source Smalltalk. What will actually happen with it is yet to be seen. In the mean time I'm hoping to find that CC validation is possible on Dynamic Languages like Smalltalk. I have a call coming up (this Thursday) with someone that has been through this, but I'm still looking for someone with experience with a lab or with a validation using a VM language. If anyone has some suggestions on someone I should talk to please let me know. I'm expecting that we will be able to make the changes necessary to the current Squeak VM to get it validated. When StrongTalk is ready maybe we can do the same, or at least consult on what should be done there. We still need a better understanding on what needs to be done. Ron Teitelbaum Squeak Cryptography Team Leader > -----Original Message----- > From: Krishna Sankar > Sent: Monday, November 27, 2006 3:38 PM > > Hi, > > Would it be easier if we work with the StrongTalk VM and embed > primitives that will enable us certification ? If we conclude that the > general VM will have difficulties to pass certification, may be, what we > need is a VM that is certified, which has minimum mods. In which case, > StrongTalk might be a good place to start. Thoughts ? > > Cheers > <k/> > > _______________________________________________ > Cryptography mailing list > Cryptography(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

3 7

Notification of publicly available cryptography code
by Ron Teitelbaum 28 Nov '06

28 Nov '06

Notification of publicly available cryptography code: Cryptography code and access to a repository for continuing development will be made publicly available on or after Monday Jan 9th 2006 as part of the Open Source Squeak Project (www.squeak.org <http://www.squeak.org/> ). The code can be accessed two ways. Either through www.squeakSource.com <http://www.squeaksource.com/> in the cryptography project or through the squeak software itself. The location for the Squeak Montecello repository using HTTP accessed through the Squeak software is: MCHttpRepository location: 'http://kilana.unibe.ch:8888/Cryptography' user: '' password: '' Thank you, Ron Teitelbaum Squeak Cryptography Team Leader

3 5

RE: [Cryptography Team] [ENH] AES
by Ron Teitelbaum 27 Nov '06

27 Nov '06

Ok I agree. I've already had someone suggest writing AES when we already had it. And who can pronounce Rijndael? I'd really like to know how he says it! Thanks I'll put it in next week. Ron > -----Original Message----- > From: cryptography-bounces(a)lists.squeakfoundation.org > [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of > cerebus2(a)gmail.com > Sent: None > To: cryptography(a)lists.squeakfoundation.org > Subject: [Cryptography Team] [ENH] AES > > from preamble: > > "Change Set: AES > Date: 24 November 2006 > Author: Timothy J. Miller > > It struck me as convenient to have an AES class. All I did was subclass > Rijndael and override new with the relevant block size and key size. I > have no idea if this is sufficient, but I suppose it's a start. Now I > need to figure out how to write tests."!

4 5

[ENH] AES
by cerebus2＠gmail.com 25 Nov '06

25 Nov '06

from preamble: "Change Set: AES Date: 24 November 2006 Author: Timothy J. Miller Refactored as a single class and did away with the factory method. Don't know what I was thinking there. New Error subclass to raise when attempting to do something valid in Rijndael that AES doesn't allow. Created Cryptography-Exceptions category as something tells me that this won't be the last exception."!

1 0

Re: [Cryptography Team] [ENH] AES
by Cerebus 25 Nov '06

25 Nov '06

On 11/24/06, cerebus2(a)gmail.com <cerebus2(a)gmail.com> wrote: > Added AES192 and overloaded the blockSize: and keySize: methods with > do-nothings (is there a better way to do this?) since they make no sense > for AES. Part of me is thinking that these should be a single class > with keySize selection at instance creation. Comments welcome."! I'm also working on a couple of tests, but I'll note that I threw a couple of FIPS 197 and RFC3602 test vectors at these classes and they came out fine. The more I think about it the more I think I'll refactor as a single class. -- Tim

2 3

[ENH] AES
by cerebus2＠gmail.com 25 Nov '06

25 Nov '06

from preamble: "Change Set: AES Date: 24 November 2006 Author: Timothy J. Miller Refactored as a single class with a stab at a factory method. Someone should probably check to make sure I'm doing the generation in a sane fashion. If an invalid key length is used, 256 is used as a default. And I should get to bed, I know. Tested with the FIPS 197 test vectors. I promise I'll work on a test class next."!

1 0

[ENH] AES
by cerebus2＠gmail.com 25 Nov '06

25 Nov '06

from preamble: "Change Set: AES Date: 24 November 2006 Author: Timothy J. Miller Added AES192 and overloaded the blockSize: and keySize: methods with do-nothings (is there a better way to do this?) since they make no sense for AES. Part of me is thinking that these should be a single class with keySize selection at instance creation. Comments welcome."!

1 0

Hello everyone!
by Joshua Gargus 25 Nov '06

25 Nov '06

Hi crypto-squeakers, I just signed up for the list, and I come with a friendship-offering of code! Before we get to the goodies, a few words about myself... I've been a Squeaker since '98 or so, and have always found cryptography fascinating. Like everyone, I don't have the time to engage in everything that I find interesting. Lucky for me, my job now gives me a reason to use and contribute the Squeak crypto codebase. I probably won't tackle broad framework issues (it looks like everyone is doing a fine job, anyway), but I expect to at least provide primitive implementations for a cipher or two. The task at hand is to implement a custom audio- and video- conferencing framework, and it needs to be secure. It doesn't need to follow standards such as SRTP (thank goodness, given the timeline), but it does need to perform well. Therefore, it needs to be implemented over UDP. I intend to implement a transport layer similar to DTLS (google rfc4347). Since this requires a cipher that can efficiently reset its state from an initialization vector (thus ruling out RC4, which we have been using for other purposes), I'll probably want to use Rijndael. Now for the goodies. I have two .mcz files that I'm attaching; I trust that they're small enough to not inconvenience anyone on dial-up: Cryptography-Core.jcg.18 - some speed improvements - a simple framework for using insecure ciphers, but not accidentally Cryptography-Insecure - a couple of trivial, insecure block ciphers for use in testing I don't fancy always sending .mcz files to the list... how does one get commit access to the repository? Or should I (for now) just send .mcz files privately to a team member who does have commit access? Thanks for all the work that everyone has done, it looks great! Cheers, Josh

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Cryptography November 2006