Cryptography

cryptography@lists.squeakfoundation.org

364 discussions

Protecting Image
by Ron Teitelbaum 11 Jan '06

11 Jan '06

All, I've been thinking though some of the problems with cryptography. I have a question. How do we protect the image? It seems to me that the easiest way to circumvent the cryptography features of a system would be to change the code to send off plain text after it was decrypted. So the question is how do we protect the image from being tampered with? Is this even a valid concern, or do we assume that once someone has access to the machine, and therefore the image, that the system is compromised in general? Ron

3 2

[ANN] Cryptography Repository Publicly Available
by Ron Teitelbaum 10 Jan '06

10 Jan '06

All, We are pleased to announce that the Cryptography Team Repository is now publicly available. We would like to thank the Squeak Foundation Board Members and the Software Freedom Law Center for your support to officially notify the US Government about this team. The work that was done allows for U.S. Citizens to post cryptography code to our repository and make that code and repository publicly available. It does not protect people from other countries and we recommend that you research and follow your local laws concerning cryptography export restrictions. The notification also does not protect people who knowingly directly export code to banned countries by way of email or other direct transfer method. The list of E1 countries is currently available on the EAR database website at http://www.access.gpo.gov/bis/ear/pdf/740spir.pdf. If you are interested in joining the Cryptography Team please let me know or you can sign up to our team list at: http://lists.squeakfoundation.org/mailman/listinfo/cryptography . Please see our wiki page and repository at www.squeakSource.com . Thank you. Please feel free to contact me with any questions or suggestions, Ron Teitelbaum Squeak Cryptography Team Leader Ron(a)USMedRec.com

2 1

[ANN] KryptOn 1.0
by Chris Muller 06 Jan '06

06 Jan '06

I'm pleased to announce the fruit of my cryptography studies! I've completely reworked the swiki page. http://minnow.cc.gatech.edu/squeak/5785 And the shiny new code is on SqueakSource and SqueakMap; much cleaned from that initial alpha version months back. I hope the months of careful consideration, detailed implementation, and high scrutiny has resulted in something useful or educational to others. Most of my guidance came from internet resources, but with notable help on difficult design decisions from John McIntosh, Andrew Gaylard, Cees and Goran. Thank you all. For the sake of confidence in this work, I have created a Swiki page specially inviting KryptOn critique. http://minnow.cc.gatech.edu/squeak/5838 Cheers! Chris

1 0

Integer>>#asByteArray - "asn1 encoding"
by Chris Muller 19 Dec '05

19 Dec '05

Does anyone mind if we rename this method to.. asAsn1Bytes or something? #asByteArray would seem to be more appropriate for getting the LargeInteger's internal representation as a ByteArray. Print this script to demonstrate how #asByteArray is exactly reversed of the Integers internal representation. | ba i | i _ 873984723987498. "a LargePositiveInteger" ba _ ByteArray new: i size. ba replaceFrom: 1 to: ba size with: i startingAt: 1. { ba. i asByteArray } This selector, #asByteArray, should have already been implemented in base Squeak and usable by serialization for example, but it wasn't yet. Nevertheless, asn1-specific code should not hog this name in the namespace. I'd like to give it back along with an implementation of #asByteArray that is congruent with its internal representation. However, I'm not sure where we are in terms of our lock down..

4 3

Re: Integer>>#asByteArray - "asn1 encoding"
by Chris Muller 19 Dec '05

19 Dec '05

Dang, ByteArray>>#asInteger is inconsistent too! --- Chris Muller <chris(a)funkyobjects.org> wrote: > Does anyone mind if we rename this method to.. asAsn1Bytes or something? > > #asByteArray would seem to be more appropriate for getting the LargeInteger's > internal representation as a ByteArray. Print this script to demonstrate how > #asByteArray is exactly reversed of the Integers internal representation. > > | ba i | > i _ 873984723987498. "a LargePositiveInteger" > ba _ ByteArray new: i size. > ba > replaceFrom: 1 > to: ba size > with: i > startingAt: 1. > { ba. i asByteArray } > > This selector, #asByteArray, should have already been implemented in base > Squeak and usable by serialization for example, but it wasn't yet. > Nevertheless, asn1-specific code should not hog this name in the namespace. > I'd like to give it back along with an implementation of #asByteArray that is > congruent with its internal representation. > > However, I'm not sure where we are in terms of our lock down.. > >

1 0

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Cryptography