Cryptography

cryptography@lists.squeakfoundation.org

364 discussions

RE: [Cryptography Team] Initial package factoring complete
by Chris Muller 28 Oct '05

28 Oct '05

Try resaving it from your Monticello browser.. > Is there a way to push your version 3 to a version 6 to remove ambiguity?

1 0

RE: SUnit?
by Ron Teitelbaum 28 Oct '05

28 Oct '05

Hans-Martin, Chris, Matt and All, Did we want to use this new test runner for SUnit for testing our code? How would we go about packaging it? Would we load it into our package or make it a prerequisite? Thoughts? (Thanks Lukas for putting it together) Ron MCHttpRepository location: 'http://mc.lukas-renggli.ch/essential' user: 'squeak' password: 'squeak' -----Original Message----- From: squeak-dev-bounces(a)lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Lukas Renggli Sent: Friday, October 28, 2005 9:05 AM To: The general-purpose Squeak developers list Subject: Re: SUnit? > It should run in Squeak 3.7 and later, with the Refactoring Browser > and the latest ToolBuilder loaded. There are certainly bugs. I built > that tool out of frustration of the existing tools that do not scale > to a large number of tests ... Ohh, and a screen-shot is available at: http://mc.lukas-renggli.ch/essential/screenshot.png -- Lukas Renggli http://www.lukas-renggli.ch

3 2

Crypto for Squeak! Yea! (and msh-crypto)
by Matthew S. Hamrick 27 Oct '05

27 Oct '05

Hey Everybody! I'm glad to hear there's interest for a 100% Smalltalk version of crypto primitives. A long while ago I started work on the "Mobile Security for Handhelds" Crypto package. Originally intended to be the crypto layer for a squeak port to PalmOS, I eventually just decided to work on it as a generic crypto package for Smalltalk. You can find a changeset and a project file at http:// www.cryptonomicon.net/msh/squeak/ . I've implemented a message digest infrastructure (including MD2, MD4, MD5, SHA1, SHA256, and somewhere I have a SHA384, SHA512 and SHA1024 implementation.) I started a SymmetricStreamCipher abstract class and a concrete implementation of ARC4. Somewhere I have a DES implementation, but quite frankly it hasn't been at the top of my mind lately. Security and flexibility were at the top of the list of design features, so I included the #clearSensitiveData method in the design to ensure that sensitive bits get obliterated before they're GC'd. Of course it's up to the developer to properly call these methods, but they're there for when you need to call them. I've talked to James about the CinCom implementation a couple of times. On thing that's a little disturbing is that he tells me that they haven't alerted BIS (formerly BXA) as to the existence of the package. The current rules for US open source crypto developers are that you have to alert the BIS (Bureau of Industry and Security) before you export (i.e. - upload to a ftp site, post to a newsgroup, or include in an email distribution that goes overseas) you're supposed to send an email message to them telling them where they can find a copy. I think this is to insure that it's really open source and to provide them with a working copy should they find bad guys are using your source. (saves them from having to reverse engineer the code.) I could be wrong about this, but you probably want to double- check with them... It's probably worth noting that the msh-crypto package, while incomplete, is distributed under a BSD style license that allows commercial and non-commercial uses and derivative works.

2 1

msh-crypto design and tests
by Matthew S. Hamrick 27 Oct '05

27 Oct '05

Hey everybody... Way back in the olden days I was part of the team at RSA that implemented J/SAFE (now called BSAFE Crypto-J.) One of the things we learned there was how important testing is. One of RSA's great bits of technology was the BTEST infrastructure. It was a series of tests that exercised the crypto primitives in BSAFE, ensuring that the implementation matched the published algorithms. For a long time these tests were buried inside the deep recesses of RSA's engineering labs in Redwood City (later San Mateo) California. But then one day RSA wanted to move a lot of their development overseas to Australia. The idea was that most of their new customers were in Japan and Australia was close to being in the same time zone which made support a lot easier. Plus, the Aussies would work for a lot less than their bay area counterparts. The fact that Eric A. Young, the godfather of OpenSSL, was in .au only made things better (he wrote the first code that would implement the API popularized by OpenSSL.) But they were faced with a problem, exporting their code to Australia was "difficult" under the existing export regulations. If you wanted to export a commercial crypto package, you had to jump through a lot of hoops; even if you were exporting things to a friendly place like Australia (I suppose someone was still worried that a communist insurrection could occur while we weren't looking.) However... this was not the case for documentation. If you wanted to type up a description of an algorithm or even a C implementation and publish it, this was okay. The law considered this to be contributing to international research efforts, not trafficking in controlled munitions. Industry watchers believe RSA was planning on re-implementing their Crypto libraries overseas to make it easier for them to fit on 16 bit mobile phones, so the only thing they were worrying about was the API. They wanted to make sure that their overseas customers had the same API (or a similar API) as BSAFE. The solution was pretty cool; they wrote a document that described the API in english text. But the text was regular enough that one could write a program to reconstruct the API from the english description of it. Pretty cool, huh? This document was published as a IETF internet draft and thus avoided the export regulations... It wasn't code, it was a description of an interface published by a well regarded organization involved in the development of the internet. So assuming you're not completely bored by this narrative, one of the very cool things that went with the API were the test suites. The test suites use industry recognized test vectors for ciphers and formats supported by the BSAFE library. In theory, it should be a trivial matter to write code to convert the document describing the test suites into SUnit tests. So... assuming we want to do "Test Driven Development," there might be some advantage to having a large pool of test vectors, irrespective of where they come from. If there's interest in this group, I'll move the SUnit tests a little higher in the priority queue. Also... there are existing test vectors in SUnit tests for msh-crypto that derive from the NIST documents and IETF RFCs. Even if you didn't want to use the msh-crypto implementation for license reasons, the SUnit tests could still be of value. (BTW... msh-crypto is distributed under a BSD license to make it usable with Spoon without having to wring ones hands repeatedly about licensing issues.) -Cheers -Matt H.

1 0

Re: [Cryptography Team] some more repository things
by Chris Muller 24 Oct '05

24 Oct '05

I can do it, but please clarify. It sounds like all we need is to name ones that are specific to any algorithm Cryptography-Base. Right? > Hi folks, > I noticed that the package cutting 'Cryptography' and > 'Cryptography-SHA256' does not work well with Monticello, since MC works > with prefixes to decide which classes and methods belong into which > package. > Just had a chat with Cees on the IRC, and asked him about this. He said > that this is a no-no and we should rather have packages 'Cryptography-*' > for all our stuff, so that no single package name is a prefix of another. > This also means that extension protocols must be renamed. > Who can do this, and when? I can't do it this weekend, and probably not > next week either, so someone else should probably go for it. > > Cheers, > Hans-Martin

4 9

DES status?
by Hans-Martin Mosner 24 Oct '05

24 Oct '05

Hi folks, I noticed that Cryptography-DES has no non-primitive version. Since the primitive is not in my current VM, I can't test it. Another issue is that interpreterProxy shows up as Undeclared when I load the DES stuff, which probably means that the primitive won't compile cleanly - but I have not looked further into this. Would you mind if I modify the DES code to fall back to the non-primitive implementation which I wrote for OpenPGP? I would have to adapt to the slightly different API anyway (my code used 8-byte Integers as keys and data blocks, while the Cryptography code uses 8-byte ByteArrays which make more sense). BTW, I've made a first cut creating separate packages (Crpytography-Core, Cryptography-ASN1, ...) which seems to work reasonably well. Once I've successfully loaded all of them into a base image, I'll publish them to our repository. I don't know how MC manages prerequisites yet, so anyone loading these would have to take care of the load order by himself. Cheers, Hans-Martin

4 4

Re: [Cryptography Team] some more repository things
by Chris Muller 23 Oct '05

23 Oct '05

> Drat, I just realized I forgot the extensions. I'll do those too.. Actually, I will wait until we decide whether want to have all separate packages for each algorithm first..

1 0

packages cut apart
by Hans-Martin Mosner 23 Oct '05

23 Oct '05

Hi folks, now I did have some unexpected free minutes, so I cut the Cryptography package apart. Preliminary load order: * Cryptography-Core * Cryptography-Support * Cryptography-SHA1 * all the others should work. For a final release, we might want to combine some of the packages so people won't have to load so many things, but for initial work on the code it's probably easier to keep them separated. One more thing: should we consider moving the ASN1 test case into Cryptography-Tests? Cheers, Hans-Martin

1 0

some more repository things
by Hans-Martin Mosner 22 Oct '05

22 Oct '05

Hi folks, I noticed that the package cutting 'Cryptography' and 'Cryptography-SHA256' does not work well with Monticello, since MC works with prefixes to decide which classes and methods belong into which package. Just had a chat with Cees on the IRC, and asked him about this. He said that this is a no-no and we should rather have packages 'Cryptography-*' for all our stuff, so that no single package name is a prefix of another. This also means that extension protocols must be renamed. Who can do this, and when? I can't do it this weekend, and probably not next week either, so someone else should probably go for it. Cheers, Hans-Martin

1 0

How many repositories does it take to screw in a lightbulb?
by Cees De Groot 22 Oct '05

22 Oct '05

I thought only one... Is there a reason that there's a load of repositories for this project? It makes almost everything harder...

3 7

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Cryptography