Cryptography October 2005

cryptography@lists.squeakfoundation.org

12 participants
19 discussions

FW: Software Freedom org Cryptography team update
by Ron Teitelbaum 31 Oct '05

31 Oct '05

All, The Cryptography Team needed a lawyer for both US Registration, and to help with talks with Cincom. I put out a call for help and someone suggested we contact the softwareFreedom org. I mentioned that we would update the group on the result of that request. I have good news, they have agreed to help. We are putting together a formal relationship this Thursday Nov 3rd 2005. I will keep you informed on our progress as we work through our issues. Ron Teitelbaum President / Principal Software Engineer US Medical Record Specialists Squeak Cryptography Team Leader

2 1

RE: Notes for Meeting with lawyers
by Ron Teitelbaum 31 Oct '05

31 Oct '05

All, As I stated before, we have a meeting with the Software Freedom Center Law Center on Thursday. My goals for the meeting are: 1) Find out how to register and comply with US export regulations regarding Cryptography. 2) Find out what the on-going maintenance requirements for the registration are. 3) Find out how to add new team members to that registration, or if new member registration is needed. 4) Find out what if any export restrictions are applicable in other countries. 5) Discuss Cincom Licensing Issues. As a result of this meeting I plan to: 1) Write up summary of meeting to share with you. 2) Write up a HOW TO export your code for other open source projects 3) Develop a step by step with check list for new members to address these issues here and abroad. 4) Get back to work. Does anyone have any additions or comments to this plan? Please let me know before the meeting. Ron Teitelbaum Ron(a)USMedRec.com

3 2

Initial package factoring complete (was: Re: some more repository things)
by Chris Muller 29 Oct '05

29 Oct '05

> > Are you sure this is a safe thing to do? My understanding is Monticello > treats > > the two-part category names as: > > > > PackageName-Category name > > > Not if you start adding packages that are named 'Package-Name' ;) >From this I gather your answer is "yes" this is what you want to do. I suppose you have a lot more confidence in the tools than I do. I think we will get bit by this someday, but I have nevertheless done what you want. We now have all separate algorithm packages. However, I decided against Monticello prereqs; one change to Base and you suddenly have to resave *eleven* packages, and we all know how buggy prereqs are. But I'll go any direction the team wants to on this.. I follwed hmm's lead on removing ASN1Constants pool dictionary, it was causing a load warning, but not sure whether it was needed or not. I know nothing about ASN1. Further, I noticed some of the base-class extensions named "decodeAsn1Der" were also used by DSA. Therefore, ALL ASN1 extensions are in the CryptographyBase package. Someone who knows about ASN1 should clean this up. Remember, you need to load CryptographBase-cmm.3.mcz, NOT version 5. Also, Cryptography-Support is not needed. After you load Base.3, then load each algorithm-specific package and, finally, the Tests package. 15 of 18 of the tests pass, just as if I load Cryptography 0.3 from SqueakMap. - Chris

4 7

export regulations (was: [Cryptography Team] msh-crypto design and tests)
by Chris Muller 29 Oct '05

29 Oct '05

> 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... I must say you have shocked me out of ignorance. Or, rather, this did: http://www.bis.doc.gov/Encryption/nlr.htm This makes no sense.. "The following items require such notification: * Mass market encryption commodities and software with key lengths not exceeding 64-bits; * Encryption items (including key management products and company proprietary implementations) with key lengths not exceeding 56-bits for symmetric algorithms, up to 512-bits for asymmetric key exchange algorithms, and 112 bits for elliptic curve algorithms." The (already exported) algorithms can be configured for larger key sizes, is this talking about default values for key lengths? But it looks like their stenographer got it backward..! It says, "the following items REQUIRE notification" but then they specify key sizes "NOT exceeding" but they surely mean exceeding. Unreal. I was on the verge of "exporting" a domain of security classes leveraging our Cryptography package. Is this about the stinkin' default values? You may have saved me from jail..

5 7

RE: About the laywers...
by Ron Teitelbaum 28 Oct '05

28 Oct '05

All, I've changed our library to no-access unless you are a developer. Until we work this out. Ron -----Original Message----- From: Matthew S. Hamrick [mailto:mhamrick@cryptonomicon.net] Sent: Friday, October 28, 2005 3:58 PM To: Ron(a)USMedRec.com Subject: About the laywers... Hey Ron... Just to let you know... I sent an email to two of the three lawyers that used to handle export stuff for us at RSA asking if they would be willing to help us on a pro-bono basis. I basically told them we're pretty sure that our export situation is covered by a TSU exemption, but we might have some questions about licensing surrounding integration of someone else's code into our codebase. Who knows... they might just have time to help us out a little... -Cheers -Matt H.

1 0

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Cryptography October 2005