Cryptography August 2010

cryptography@lists.squeakfoundation.org

3 participants
6 discussions

Start a nNew thread

test
by Rob Withers 30 Aug '10

30 Aug '10

1 0

test again
by Rob Withers 29 Aug '10

29 Aug '10

test

1 0

test
by Rob Withers 29 Aug '10

29 Aug '10

test

1 0

test - ignore
by Rob Withers 29 Aug '10

29 Aug '10

ignore

1 0

Re: [Cryptography Team] Re: [squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractively is not random
by Rob Withers 28 Aug '10

28 Aug '10

Andreas, I will volunteer to take this on. I think it is a good idea. I need write access to the trunk repository, I believe. Can you help me with that? I am not sure how inbox gets used or whether I should use it. >From what I have gathered that you said, we should have the following packages: CryptoCore CryptoCoreTests CryptoExtras CryptoExtrasTests Certificates CertificatesTests Can you confirm this and that all would become Truck packages? A question below.... -------------------------------------------------- From: "Andreas Raab" <andreas.raab(a)gmx.de> > 2) It has too many variations (all those *WithPrimitive and > *NonPrimitive) variants. There's no need to have both; write the > primitive variants so that they use non-primitive fallback code or > simply require the primitives. This really isn't so bad. There are 4 plugins, and so there are 4 *WithPrimitive and 4 *NonPrimitive variants. I suggest for phase 1 we leave these alone. The issue is that in some cases the algorithm used for the Primitive is different than the algorithm used in the image. It will take some thinking to write non-primitive fallback code and untangle the algorithm class to use it. A worthy goal but not something that prevents us from packaging Crypto into the Trunk. Cheers, Rob > > 3) ASN1, X509, PKCS. This is not cryptography, this is certificate > handling. It should be in a Certificates package, not Cryptography. > > 4) A category per class. Puh-lease... > > If you do all of the above you'll end up with one or two "Crypto-Core" > categories containing all of the "essentials" like MD5, Triple DES, DSA, > RSA, SHA1, SHA256. That's probably about what you'd want in the base > image and I'd be surprised if it's more than 20 classes. I think you > could make a *very* reasoned case that this Crypto-Core should be > included in the trunk image by default in particular considering that it > would remain loadable and simplify the System (and other) packages. > > Then you have Crypt-Extras with the less common stuff, from MD2 to > DiffieHelman. On top of which is the Certificate package with ASN1, > X509, and PKCS. On top of which is the SSL stuff. > > I think this would be quite a nice structure and I'd be supporting > getting a small Crypto-Core package into trunk. Anyone up for it? > > Cheers, > - Andreas > > > -------------------------------------------------- > From: "Chris Muller" <asqueaker(a)gmail.com> > Sent: Thursday, August 26, 2010 7:02 PM > To: "Cryptography Team Development List" > <cryptography(a)lists.squeakfoundation.org> > Cc: "The general-purpose Squeak developers list" > <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [Cryptography Team] Re: > [squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractively is not > random > >> DigitalSignatureAlgorithm, SecureHashAlgorithm and >> ThirtyTwoBitRegister have been part of Squeak for a long time, there >> are legacy users, although I think they should migrate to using the >> counterparts in Cryptography. >> >> Folding Cryptography into Squeak would probably go against the >> political momentum toward smaller, more modular images. We don't need >> to do something that drastic just to solve this issue. >> >> I suggest instead that we merely move two utility methods from >> Cryptography: >> >> RandomGenerator class>>unpredictableStringsDo: aBlock >> RandomGenerator class>>generateKey >> >> to Random class in Squeak, and then employ them in >> DigitalSignatureAlgorithm for its #initRandomNonInteractively. >> #generateKey should be patched up from its dependence on Cryptography >> methods. >> >> This allows Squeak to purge the insecure approach of grabbing bits >> from a (silent or disconnected) SoundService, in favor of the robust >> one in Cryptography (except now moved to Squeak). >> >> - Chris >> >> >> >> >> On Mon, Aug 23, 2010 at 10:09 AM, Rob Withers <reefedjib(a)gmail.com> >> wrote: >>> Hi Chris, >>> >>> It works really well. The only issue now is the >>> DigitalSignatureAlgorithm >>> is located in the core squeak image and the changes I made are in the >>> Cryptography package. It would be nice to fold Cryptography into the >>> core >>> squeak image, or pull DigitalSignatureAlgorithm out into Cryptography. >>> >>> Rob >>> >>> -------------------------------------------------- >>> From: "Chris Muller" <asqueaker(a)gmail.com> >>> Sent: Sunday, August 22, 2010 5:35 PM >>> To: "The general-purpose Squeak developers list" >>> <squeak-dev(a)lists.squeakfoundation.org> >>> Cc: "Squeak Crypto" <cryptography(a)lists.squeakfoundation.org> >>> Subject: [Cryptography Team] Re: [squeak-dev] >>> DigitalSignatureAlgorithm>>#initRandomNonInteractively is not random >>> >>>> Good, SecureRandom employs its #generateKey method (on the class side) >>>> to initialize its 'picker' (class-instance var). This was intended to >>>> serve as a globally usable SecureRandom so that clients like >>>> DigitalSignatureAlgorithm would not have to define their own. >>>> >>>> On Sat, Aug 21, 2010 at 5:30 AM, Rob Withers <reefedjib(a)gmail.com> >>>> wrote: >>>>> >>>>> I found a problem with >>>>> DigitalSignatureAlgorithm>>#initRandomNonInteractively. It is >>>>> grabbing >>>>> randomBits from the SoundSystem, but I may not have that installed. >>>>> It >>>>> gave >>>>> me the same bits repeatedly. I modified >>>>> DigitalSignatureAlgorithm>>#initRandomNonInteractively to not rely on >>>>> the >>>>> SoundSystem and instead use SecureRandom. This is published in the >>>>> Cryptography repository. >>>>> >>>>> Rob >>>>> >>>>> >>>> _______________________________________________ >>>> Cryptography mailing list >>>> Cryptography(a)lists.squeakfoundation.org >>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography >>>> >>> _______________________________________________ >>> Cryptography mailing list >>> Cryptography(a)lists.squeakfoundation.org >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography >>> >> >> >

2 1

[Cryptography Team] DigitalSignatureAlgorithm>>#initRandomNonInteractively is not random
by Rob Withers 26 Aug '10

26 Aug '10

I found a problem with DigitalSignatureAlgorithm>>#initRandomNonInteractively. It is grabbing randomBits from the SoundSystem, but I may not have that installed. It gave me the same bits repeatedly. I modified DigitalSignatureAlgorithm>>#initRandomNonInteractively to not rely on the SoundSystem and instead use SecureRandom. This is published in the Cryptography repository. Rob

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Cryptography August 2010