Cryptography November 2005

cryptography@lists.squeakfoundation.org

9 participants
10 discussions

Password Safe
by Ron Teitelbaum 21 Nov '05

21 Nov '05

All, Does anyone have any information about the program password safe? Specifically I'm looking for information about how secure the program is what encryption algorithms it is using are they implemented properly. What if any experience anyone has with the program. Does it support logging? Is it stable enough to use in a banking environment? Thanks for your help! I will make it clear later how this relates to squeak. Ron Teitelbaum President / Principal Software Engineer US Medical Record Specialists Squeak Cryptography Team Leader

1 0

Team Update
by Ron Teitelbaum 16 Nov '05

16 Nov '05

All, I just wanted to give everyone an update on what's going on. So far we have reached an agreement with the SqueakFoundation to allow us to establish a relationship with the Software Freedom Law Center. They are currently working on official US Cryptography Export Notification. Once that notification is done and we receive a response from the government validating that we did things properly, we will open back up the repository. It also appears that there is little we can do to figure out export requirements for other countries. Cees mentioned that there are no export requirements where he is. Maybe we could start a list of contributors and countries and what the requirements in each country are. Does anyone else outside the US know what the cryptography Also once the relationship is settled we will again approach Cincom about a port of their cryptography code. (Sean have you heard any new comments from James?) In the mean time I am still working through ASN.1. We have a new official Team Member: Paul Davidowitz. Paul and I have worked before he is a very solid programmer. We have discussed ASN.1 and Paul is working through some possible designs. Please welcome Paul to the team! Also if you have subscribed to this list and would like to join the team, please speak up and let us know. The repository is closed now and is only available to official cryptography team members. Thanks everyone for your patience while we work through these startup issues, Ron Teitelbaum Cryptography Team Leader

4 9

[ANN] KryptOn
by Chris Muller 09 Nov '05

09 Nov '05

Thanks for the feedback you guys. I have made significant updates to the Swiki page (worth scanning the "High-transparency and convenience" section one more time) and posted code to SqueakSource and SqueakMap too. I sent the TSU email notification as Matthew suggested. > I hardly think that anyone's first guess for an application is a > Team's repository. I completely agree, and there may even be other reasons to keep it separate. I created it as a separate SqueakSource project, "KryptOn". > Are you asking for a critique of the KryptOn architecture or > opinions on whether you should post the code? I would love a critique. - Chris

1 0

opinions?
by Chris Muller 09 Nov '05

09 Nov '05

Well, I'd love to post the KryptOn code.. Ron, can you gauge from your meeting last week or anyone else with knowledge of this subject, after reading the description of KryptOn what do you think? http://minnow.cc.gatech.edu/squeak/5785 I'm not looking for legal advice (but I'll take it if someone offers), just "gut feelings" from you guys who know a lot more about it than I do. Safe to post this on squeaksource? Swiki is in the US, maybe that would be even safer..? Thanks, Chris

4 7

Re: [croquet] MC passwords in images?
by Bert Freudenberg 07 Nov '05

07 Nov '05

You may have missed Cees De Groot posting an RC4 / SHA-1 vault for Squeak: http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-November/ 096897.html Or me posting access code to Mac OS X's system-wide Keychain: http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-November/ 096837.html And Andreas actually patching Monticello to store passwords outside the image: http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-November/ 096909.html Regarding zeroing out passwords: the snapshot primitive always does a full GC, so niling out the entry is sufficient. If you are paranoid, make the former password string #becomeForward: nil, which nils out not only this reference, but every reference to it in the system. - Bert - Am 07.11.2005 um 18:57 schrieb Matthew S. Hamrick: > 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

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 06 Nov '05

06 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Cryptography November 2005