Cryptography January 2006

cryptography@lists.squeakfoundation.org

9 participants
12 discussions

Notification of publicly available cryptography code
by Ron Teitelbaum 28 Nov '06

28 Nov '06

Notification of publicly available cryptography code: Cryptography code and access to a repository for continuing development will be made publicly available on or after Monday Jan 9th 2006 as part of the Open Source Squeak Project (www.squeak.org <http://www.squeak.org/> ). The code can be accessed two ways. Either through www.squeakSource.com <http://www.squeaksource.com/> in the cryptography project or through the squeak software itself. The location for the Squeak Montecello repository using HTTP accessed through the Squeak software is: MCHttpRepository location: 'http://kilana.unibe.ch:8888/Cryptography' user: '' password: '' Thank you, Ron Teitelbaum Squeak Cryptography Team Leader

3 5

Re: Cryptography Digest, Vol 4, Issue 14
by Paul Davidowitz 23 Jan '06

23 Jan '06

Nevermind, I found it in the doc regarding references. - Paul Davidowitz On 1/23/06, cryptography-request(a)lists.squeakfoundation.org <cryptography-request(a)lists.squeakfoundation.org> wrote: > Send Cryptography mailing list submissions to > cryptography(a)lists.squeakfoundation.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography > > or, via email, send a message with subject or body 'help' to > cryptography-request(a)lists.squeakfoundation.org > > You can reach the person managing the list at > cryptography-owner(a)lists.squeakfoundation.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Cryptography digest..." > > > Today's Topics: > > 1. ASN Name Uniqueness (Ron Teitelbaum) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 22 Jan 2006 19:13:56 -0500 > From: "Ron Teitelbaum" <Ron(a)USMedRec.com> > Subject: [Cryptography Team] ASN Name Uniqueness > To: "'Cryptography Team Development List'" > <cryptography(a)lists.squeakfoundation.org> > Message-ID: > <!&!AAAAAAAAAAAYAAAAAAAAALn4DBa9j89Bkul53Jf1ky/CgAAAEAAAAGRRmHwQc+hApC3hBGC4+wMBAAAAAA==(a)USMedRec.com> > > Content-Type: text/plain; charset="us-ascii" > > All, > > > > I seem to remember reading that names can only be represented once in an ASN > module. Can anyone verify the rules for name uniqueness in ASN? > > > > Ron > >

1 0

ASN Name Uniqueness
by Ron Teitelbaum 23 Jan '06

23 Jan '06

All, I seem to remember reading that names can only be represented once in an ASN module. Can anyone verify the rules for name uniqueness in ASN? Ron

1 0

Sorry forgot the link
by Ron Teitelbaum 22 Jan '06

22 Jan '06

http://www.erlang.org/ Ron

1 0

FW: yet another smallest snapshot, and a visualization
by Ron Teitelbaum 22 Jan '06

22 Jan '06

Paul, I saw this post on squeak-dev. When looking at the software I noticed that it has built in support for ASN.1. I'm not sure if it will be of any help to what you are working on but I thought I'd point it out to you, if you want to take a look at their code. Ron -----Original Message----- From: squeak-dev-bounces(a)lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Todd Blanchard Sent: Saturday, January 21, 2006 10:02 PM To: The general-purpose Squeak developers list Subject: Re: yet another smallest snapshot, and a visualization I just got an introduction to erlang, this sounds kind of like that. Lots of interesting concepts worthy of theft in that language. On Jan 21, 2006, at 10:56 AM, Colin Putney wrote: > > On Jan 21, 2006, at 12:28 AM, tim Rowledge wrote: > >>> This is interesting to me. Do you think it is feasable to take >>> out all of the process management from the VM and put it back in, >>> say, via a plugin? >> I think so. No need for the special objects array or Processor >> instance if the saved context oop is either explicitly saved in >> the image header or simply put somewhere by convention (like nil >> true and false used to be) which would be trivial with Craig's >> version of the tracer. You could start a copy of a VM for each >> process and terminate it when the process concludes. This VM would >> need no process handling stuff such as wakeHighestPriority but >> might need some semaphore stuff? >> Debugging might be fun. Coordinating threads would have the >> potential for getting to be as awful as java. On the other hand it >> wold be an interesting way of making completely separated cells of >> objects each running their own process and having to communicate >> only via proper interfaces instead of messing in a global object >> soup. All sorts of fun possibilities if one has the tim and funding > > Indeed. The end result would be message-passing concurrency, rather > than shared-state concurrency. Each VM instance would be a Vat/ > Island/Task and you'd have distant object references for sending > messages between them. VM instances could also be on a separate > thread, in a separate process or on a separate machine, depending > on what kind of performance characteristics you were looking for, > pretty much transparently. Beautiful. >

1 0

Re: Protecting Image
by Chris Muller 20 Jan '06

20 Jan '06

> But the moment the user modifies something in the > image and saves it, > you've invalidated the signature. So signing and > verifying the whole > image probably won't work. What do you think of launching images from a trusted image via OSProcess? Immediately after saving an image, a hash for its .image file contents is computed. This hash is stored in a secure place (i.e., your keyring or sealed in a Capability). Later, to launch that saved image, you use a "SecureLauncher" class from your trusted image. SecureLauncher computes the hash of the .image you want to launch and looks for that specific hash on your keyring. If its not there, a Warning or Error is signaled..

1 0

community-developed KryptOn
by Chris Muller 17 Jan '06

17 Jan '06

I want to thank everyone for the KryptOn 1.0 comments. A couple of improvements have been identified (getting rid of that ECB mode and using "associated data"..) and that helps immensely. I will work on these and post an update soon. But my hope is that KryptOn will, going forward, be community-developed so that it has the benefit of everyones collective knowledge. I racked my brain for months trying to account for insidious attacks such as "replay attacks" and believe I have this sort of attack (among others) solved. The result is what I hope is a "good start" that can be "taken over" by the community with more crypto knowledge. I also spent a lot of time accounting for the *usability* of KryptOn. For example, it absolutely omits API that pretends to solve the initial-key-exchange problem. That's why API is provided only to export to a file, not a Stream (i.e., SocketStream), and the instructions say to exchange "in person or via a trusted third party." Usability is an area where I think my skills bring something to the table. My goal is for Squeak to have an OO security solution that is easily groked, critiqued, fixed and used. I know there is no "absolutely" secure remedy (except maybe one-time pad) but, in terms of the levels of gray, I know Magma has gone from completely white (insecure) to some shade of dark gray. Deep down, I believe it is now, at a minimum, "secure" from the population that are not cryptanalysts (I myself couldn't begin to plan an attack against a running server). This is worth something isn't it? To me, it is. I guess I'm quite surprised by the "fear and mystique" surrounding implementation of basic PKC protocol. Is everyone here saying that, despite having been around since 1976 (thirty years!), PKC best-practices are still so complex, dark and mysterious that we should not even attempt it? > Would it make sense, for instance, to have a > Smalltalk implementation of > OpenPGP, http://www.ietf.org/rfc/rfc2440.txt ? It's > good for encrypting > and signing messages, all the design's been done, > it's widely > implemented, and it has already been *extensively* > analysed. Could > KryptOn become an OpenPGP? With this we would send cleartext outside the image to this external, highly-complex, non-OO, differently-licensed, implicitly-trusted PGP module? Maybe there is a place for that sort of solution to pacify corporate interests that want the "certification" assurance. But, some of us just want real security, not official certifications. As software developers, we can feel confident with our own work because we understand it all the way down and it has been reviewed by our peers whom we trust. And implementing this complex spec will not eliminate the need for extensive critique and testing. And it does nothing for capabilities authorization, which KryptOn provides now.. So how about start with KryptOn, a pure OO solution, apply the design principles in that OpenPGP spec, "rip KryptOn to shreds" so we can then patch it up together, as a commmunity, and all learn something in the process.. The pure-OO solution is an opportunity for us take charge of our own software-destiny and to "document," via high-clarity implementation, a secure way to do PKC protocol with objects once and for all.. Andreas expressed an interest in KryptOn for Croquet security (http://minnow.cc.gatech.edu/squeak/5838). Only the cryptography team, *as a community*, can have the knowledge and clout to help the Croquet team out. I'm asking for help, I want to move forward with KryptOn. I'm ready to add any of you to be developer on KryptOn to the SqueakSource project. Best Regards, Chris

2 1

Re: KryptOn MakoEnvelope signedAndSealedFrom:to:object:
by Chris Muller 12 Jan '06

12 Jan '06

Hi Tony, it may very well be the other way around. I am honestly no encryption expert, just a skilled implementor. I will try to find the web reference that recommended that. As for ECB, I'm sorry I have no idea what that means. This is exactly the kind of critique I need your guys' help with. I am hoping that the usage and management are mostly ok, but there may be some tightening needed in the cryptography layer. This is a very worthy discussioon for the cryptography list, I hope you don't mind that I have copied that list here. Cheers, Chris --- Tony Garnock-Jones <tonyg(a)lshift.net> wrote: > Hi Chris, > > In the comment to method MakoEnvelope > class>>signedAndSealedFrom:to:object:, you write > "Security experts > recommend putting the signed inside the sealed". > > Isn't it the other way around? According to > http://www-cse.ucsd.edu/users/mihir/papers/oem.html > the least insecure > method is to encrypt, then MAC. > > Also: On digging into the implementation of > enciphering, it looks like > the default cipher, Rijndael, is being used in ECB > mode. Have I analysed > that correctly? (If so, there are other modes that > might be better: AEAD > modes such as EAX or GGM; at a minimum, CTR, but an > AEAD mode would be > better, of course) > > Regards, > Tony > -- > [][][] Tony Garnock-Jones | Mob: +44 (0)7905 > 974 211 > [][] LShift Ltd | Tel: +44 (0)20 7729 > 7060 > [] [] http://www.lshift.net/ | Email: > tonyg(a)lshift.net > >

6 15

Re: KryptOn MakoEnvelope signedAndSealedFrom:to:object:
by Chris Muller 11 Jan '06

11 Jan '06

> ECB, CTR ("Counter"), EAX and GGM are all modes of > operation for block > ciphers. This wikipedia page > http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation > provides a > good overview of the different modes, and why ECB is > a bad choice Ok, yes, KryptOn 1.0 is using ECB mode. This is very easily changed, though, the method is BlockCipher>>#makoEncrypt:. > (I was particularly struck by the spectacular > failure of ECB mode to > encrypt the sample image!) That surprised me too, but then thinking about it makes sense because all the background pixels are the same color, therefore they are encrypting to the same bits. So the background color changes but the "disturbed" pixels (other than the background color) are causing the original shape of the original image to show through. > With specific reference to a Mako signed-sealed > envelope, probably the > best thing to do is to perform the public-key > signing operation on the > original data, and then encrypt-and-MAC the signed > data as a separate > step. The thing to do is to change the way envelopes > are sealed (the > signing process can be left alone) to be an > encrypt-and-MAC operation > rather than a simple encrypt-only operation with no > integrity > protection. For instance, Rijndael in EAX or GGM > mode would do nicely > for the enciphering step. Ok, if this is the right thing to do then I will try to make these changes. > Another thing to watch out for is the key-exchange > protocol, which can > be really sensitive. Ok, if you have any suggestions please let me know here on the cryptography list. Regards, Chris

3 4

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Cryptography January 2006