Cryptography

cryptography@lists.squeakfoundation.org

364 discussions

Re: [croquet] MC passwords in images?
by Matthew S. Hamrick 07 Nov '05

07 Nov '05

Hi Andreas, et al, Sorry for cross posting on every Squeak-related list I read, but it seems like everyone has been talking about security lately. I think the problem is more than just plain-text passwords for repositories. If you dig around a stock 3.8 image (with not too many packages loaded) you find a lot of places where the user is prompted for passwords. The short list includes Celeste POP3 login, Scamper HTTP basic/digest authentication, not to mention various SqueakMap, Project serverDirectories, and MC usages. There are, in short, many reasons why one would want something like this for application code as well as simply holding a password for MC. Most OSes and application environments I know of that deal with this problem implement a "vault". This is what Chris Muller was talking about with KryptOn. Vaults tend to put a bunch of "secrets" in a file somewhere with the secrets encrypted with a symmetric key derived from a user supplied pass-phrase. The application itself doesn't really have the secret (in this case a password for a MC server), but rather a reference to the secret. The first time any application needs a secret in the secrets file, the application queries the user for the master passphrase used to encrypt the secrets file. The passphrase is used along with an algorithm from something like PKCS#5 or PKCS#12 to generate the secret key used to encrypt the master secrets file. Before saving the image, the master pass phrase and any "unshrouded" secrets are expunged from memory to prevent enquiring minds from sifting through the image to recover them. You could use such a facility to store all your MC repository passwords as "secrets" in the "secrets" file, encrypted with some master, easy to remember, yet hard to guess passphrase. (rules for proper selection of passwords can be found at http://www.netfunny.com/ rhf/jokes/92q3/selpass.html ) It sounds like you're asking for something similar, but not exactly the same. It sounds like you're simply asking for a vault with no master password where secrets are simply stored outside the image. That way when the image is transferred, the passwords for the various servers stay on your machine. Personally, this seems a little reckless to me, but then again I'm a little paranoid. I think what would make me happy is to provide you with a facility that could be used safely (like with a master password,) but if you're cool with your current security position and don't think you need a master password, it shouldn't get in your way. (i.e. - it should be legal to specify a null password.) PKCS#5, SHA256, and ARC4 are supported in the existing msh-crypto codebase (at http://www.cryptonomicon.net/msh/squeak/msh- crypto.html ), so in theory it should only take a bit of glue code to figure out when to query the user for the master passphrase and when to expunge master passphrases and shrouded secrets from the image. My goal with msh-crypto was to eventually support PKCS#11 (Cryptoki) or PC/SC (aka MUSCLE) to ensure that your secrets remain with a hardware key token (like a smart card) instead of on your hard drive. In some attack scenarios, this makes your complete system (not just your image) more secure. Chances of me getting to this for Squeak are virtually nil. Chris Mueller's idea of putting your list of secrets on a JumpDrive is a good one. In fact, my GPG and PGP keys reside on a jump drive (as does the MacOS-X keychain with all my important stuff.) Here are a few other things to consider... 1. I think I saw Chris mention that he invalidates his password cache in response to a message previously registered with SystemDictionary>>addToShutDownList:. I was pleased (from a security standpoint) to see that SmalltalkImage>>saveSession sends #shutDown to all classes in the shutdown list even if it's just saving. This is sub-optimal from a usage perspective as it requires users to re- authenticate after saving, which could cause some people to feel the system is randomly forgetting passwords. I don't know of a simple way to avoid this, and I don't think the current behavior should be changed. 2. If you look at the current implementation of Password (do we really use this class, btw?) you'll see that the thing it does in response to #shutDown is to equate it's password cache with nil. WRONG. Just because you don't have a reference to it doesn't mean it has been GC'd. A bad guy can run the unix command "strings" on the image to see if they can find the password in non-GC'd memory. SecurityManager is a little smarter about the whole affair, zeroizing bits of memory which may have contained sensitive keys. If you think you're safe because you're storing a secret or private key in memory and there's no way that strings would detect that, I remind you that there are several entropy scanners that do a bang-up job of finding keys in arbitrary runs of executable code and data. 3. Licensing. uhg; licensing. My code comes with a BSD (rather than Squeak-L or MIT license) So to summarize... a. you might want to have something like a Password or a SharedSecret class to provide services to all consumers of password-based authentication services. b. a simple, albeit not especially well tested one for Spoon is about to appear at http:// c. the code is licensed under a BSD style license, so it's unlikely to be directly integrated into Squeak. However... I think we're making progress on the licensing front, so who knows. Both BSD and Squeak-L are "open" licenses, so feel free to look at my code and draw whatever benefit you can from it save removing my name or suing me because it didn't produce julienne fries for you. On 4 Nov 2005, at 11:08, Andreas Raab wrote: > Hi Folks, > > I just noticed that I handed out a whole bunch of images with plain- > text passwords for various of the more sensitive repositories, > thanks a lot (and no, if you have one of those it won't work any > longer - I changed them). So for those of you who use MC and at > times pass images around it is probably useful to check who's been > in those repositories recently. > > Oh, and is anyone out there interested in implementing a password > manager that stores passwords *outside* of an image in a reasonably > secure location? > > Cheers, > - Andreas > >

1 0

KryptOn code
by Chris Muller 07 Nov '05

07 Nov '05

I have working code with tests, but I have not posted yet, sorry. I am curious whether notifications may be required..

1 0

pre-[ANN] KryptOn
by Chris Muller 07 Nov '05

07 Nov '05

> Oh, and is anyone out there interested in implementing a password > manager that stores passwords *outside* of an image in a > reasonably secure location? I have been working on this very problem for the last few months and have (what I think to be) a very nice solution which I call "KryptOn". For best results, "passwords" (more correctly, private-keys) are intended to be stored on one of those USB microdrive devices. My wife just bought me this one for anniversary gift: http://www.knifecenter.com/kc_new/store_detail.html?s=VN53975 (That is not an endorsement). KryptOn can be leveraged by any program to provide highly-transparent security based on the principles suggested for Croquet at http://minnow.cc.gatech.edu/squeak/3770 and it never leaves your passwords exposed in a saved image; it first overwrites the bytes and then dereferences them during #shutDown of the image. I have put some information about it on the Swiki: http://minnow.cc.gatech.edu/squeak/5785 Questions or comments are very welcome. - Chris

1 0

Re: [Cryptography Team] Cryptography Team and Freedom Software
by Chris Muller 04 Nov '05

04 Nov '05

Ron, IMO this work you are doing is filling a major gap needed by the Squeak community. To solidify and clarify the licensing from pro's is something that, as Cees mentioned, no one has really been able to tackle in a way that (will) leave its interpretation as unambiguous as possible. Great job, major thanks! - Chris

1 0

RE: Notes for Meeting with lawyers
by Chris Muller 04 Nov '05

04 Nov '05

> My goals for the meeting are: > > 1) Find out how to register and comply with US export regulations > regarding Cryptography. > .. Hi Ron, my main question centers around what are the requirements for non-cryptographic software that merely *uses* already-exported cryptographic software? Specifically, would key-management software? What about if I used our existing Cryptography package to secure Magma? In that case, do they want to be notified about Cryptography, Magma, neither or both? Where is the boundary on one side of which requires registration and the other side does not? What you're doing is really going to help us all out, thanks!! - Chris

4 4

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Cryptography