Cryptography February 2006

cryptography@lists.squeakfoundation.org

5 participants
10 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

Niels Ferguson, Bruce Schneier. "Practical Cryptography"
by Chris Muller 06 Mar '06

06 Mar '06

How's everybody doing around here? I wanted to let you know, thanks to Tony, Ron, Cees and Matthew's feedback I've gone back to the drawing board to improve my crypto knowledge. After having battering-rammed my brain through most of Alfred J. Menezes, Paul C. van Oorschot and Scott A. Vanstone "Handbook of Applied Cryptography", I then picked up Niels Ferguson and Bruce Schneier's "Practical Cryptography" last week and have practically inhaled the first half of it in one breath. So easy and refreshing. Most of the books and papers I have read to this point are from the ivory tower, mostly oblivious to real-world practical security issues, especially that of human comprehension and error. Worse, even after working through some of these difficult papers to get one gold "implementation nugget" I then find other material that contradicts it! For example, the envelope composition issue (MAC-then-encrypt vs. encrypt-then-MAC).. So what's one to do, just give up? That's not an option for me, I have to move forward. I spoke with a couple of security experts at C5 and they agree with Schneier, "Cryptography is hard" and "no one can know everything about it." Therefore, at some point, I have to choose to trust some information source and go with it. I've decided to make it this 2003 book because: 1) everyone, including those on this list, seem to acknowledge Schneier as an expert 2) the book is written (as it directly claims to be) for the purpose of implementing secure crypto systems with focus on real issues. 3) seems to, more than any other source I've come across, acknowledge real-world implementation issues regarding crypto; including factoring human-frailty into the security equation (i.e., problems such as complexity). I like and agree with this philosophy. This book (purportedly) gives the average crytologist-wannabe the advice necessary to implement secure protocols. One idea of the book is to throw away mathematical interactions between the crypto primitives that permit certain kinds of attacks. Just a few interactions between primitives, assuming you're aware of them at all, quickly explode into many permutations very hard-to-analyze, hard-to-remember, and essentially insecure because of the hideous complexity. They therefore describe how to implement "ideal" primitives that do not suffer from these weaknesses. These implementations are typically slower than their non-ideal counterparts, but the authors claim the idea is to put security first because "there are enough fast, insecure systems out there.." So far, I really like this book and its philosophies. Has anyone else read the book? Cheers, Chris

3 2

CryptographyError
by Chris Muller 21 Feb '06

21 Feb '06

As a way of starting to move away from generic Error signaling, I am adding CryptographyError to be signaled when various.. well, cryptography errors occur. Adding it to CryptographyBase, it inherits from Error, no biggie. - Chris

1 0

CryptographyBase-cmm.11
by Chris Muller 21 Feb '06

21 Feb '06

Since SecureRandom uses SHA1 anyway, I returned to utilizing it for the convenience method, #withGeneratedKey. This makes it much more robust.

1 0

type some random characters to seed the random numbers (was: CTR mode, SecureRandom, ElGamal updates)
by Chris Muller 18 Feb '06

18 Feb '06

Hi Pakala, > Hi, > Thank you. It is just a small project so no need to > worry about the hacker. I gather this refers to the (low) potential that your users will be able to hack "obscured" cleartext (mildly encrypted), even if not very secure from a skilled hacker. I made a big jump when the "adversarial setting" of digital security was spelled out for me. Because digital bits are fluid and unbounded, able to travel so far, so quickly, you won't know when an attacker is attacking and, even if you did, usually nothing could be done about it. Therefore, the adversarial setting must be assumed that all data sent out of your computer (and, in extremely paranoid cases, the memory inside your computer) is sent to the attacker along the way, where they can do what they wish including modify it. The same for data received. The adversary is a mathemetician with a supercomputer, has lots of time and lots of incentive. He's ready to inflict maximum hurt. This is the setting, therefore the goal must be to provide "mathematical protection." To reveal or modify information, the adversary must solve a mathemetical problem that, so far, no mathmetician has been able to solve. > Can you please give me some more information how to > proceed. > you said that the GPG ask the user to type some > random charaters to seed the > random numbers and we can give fingeprint image. I > need some more > information about that.If you have any code please > send me. To do this, print this in a workspace: SecureRandom fromUser nextRandom160 Cheers, Chris

3 2

CTR mode, SecureRandom, ElGamal updates
by Chris Muller 17 Feb '06

17 Feb '06

Hi, this is just note to keep everyone informed about what I've done. Sorry its long, I will try to keep it newsworthy and dense. I have begun committing my initial Cryptography improvements as promised. I just committed the following to our repository: For CryptographyBase: - Updated all usages of standard Random to use SecureRandom. This now allows calculation of 512, 1024, 2048 and, computational power permitting, larger keys. According to Schneier, Ferguson - "Practical Cryptography" p. 217: "A prime of 2048 bits can be expected to secure data until around 2022; 3072 bits is secure until 2038; and 4096 bits until 2050." ... "Be careful with these kinds of predictions." - Extended SecureRandom with #nextInt: and #nextFrom:to:. The implementation just keeps calling nextBits: until an in-range is returned, and it passed a simple dispersion test. - As a substitute for Collection class>>#randomForPicking, we now have SecureRandom class>>#picker. This keys of this are wiped out and regenerated on every image save, since saving the key to disk is not recommended. - Added SecureRandom class>>#withGeneratedKey. This enumerates a series of relatively unpredictable Strings such as the bitmap of the current Squeak desktop, mouse position, Timer values, etc. - Fixed printOn: For Cryptography-Core: - Addition of CTR (counter) cipher mode. In "Practical Cryptography" Schneier reasons this is preferred mode due to its simple implementation and no need for padding. - Added LargePositiveInteger>>#destroy to permit wiping of keys from the image at proper times. For Cryptography-ElGamal - Now using SecureRandom instead of (insecure) Random. For Cryptography-Tests - The ElGamal cryptography tests let us down in terms of testing for practical usage. They were using 15-bit keys which totally obscured the problem with the Random, which could not even generate numbers large enough for the primes associated with 2048-bit asymmetric keys (not to mention 1024 and 512!). Therefore, I upgraded the tests to use 384 (generated), 512, 1024, 2048 bit ElGamal keys. The 2048-bit took 10 hours (!!) to generate, so I instantiate with its #storeString so that the tests run quickly. - Also beefed up the associated DiffieHellman test to use 384 bit keys (probably should test these with the same key sizes as ElGamel). - Because of the enhanced tests, there are more methods, so I recategorized according to what they are testing; "ElGamal", "DSA", "RSA", etc. However, I'm beginning to think we should move these tests to their individual packages of what they're testing. What does everyone else think? That's all for now, I hope you like it..! - Chris

3 4

PrimesFinder using #atRandom
by Chris Muller 14 Feb '06

14 Feb '06

Has anyone tried ElGamalKeyGenerator new generateKeysOfSize: 2048 ? The ElGamal tests pass because they use but a 15-bit key! Does anyone mind if I beef up this test and possibly others? I can post notice of my commit here when I'm done and then someone else can review it if they want? The tests will not pass unless we fix the issue itself. The issue itself appears to be caused by use of the Float-based "Random" generator. I haven't yet tried replacing it with SecureRandom, but I will try that soon.

2 2

RE: Looking for Cryptography maintainers SHA256 added to Mantis
by Ron Teitelbaum 14 Feb '06

14 Feb '06

Hello! It's great to hear from you. I have been trying to reach you and have posted to the general news groups trying to find your new email. I got your email from your package on squeakMap. We started up the squeak cryptography team and have started working on our plans for development. We have really two major goals. First to write cryptography software that makes it easy for people to integrate cryptography into their software. Second to have a cryptography library that is safe and secure and acceptable to the business community. I have very strict requirements for my own application and I believe that by better rounding out our offering we can attract more business developers. Along that line I began talking to Cincom about porting some of their code. I haven't followed up with James Robertson yet because I have not had the time, but that is one of the things we would like to look into. The major stumbling point with Cincom was the license issue. James says he is looking into the possibility of licensing their code as MIT. We are currently working on an ASN.1 framework. The goal is to try to provide the same benefits in Smalltalk that C++ programmers have today, and to use the same framework in many different ANS.1 implementations. Paul Davidowitz is leading the development effort and should have something to post soon. We are planning on using this framework to develop x509 v3. Also I would like to see the ASN.1 framework used to provide access to other business protocols like X12 (that would shake things up). We have just started the process of looking into Government Certification and are looking at the OpenSSL FIPS program. Also Hans-Martin is working on his PGP implementation, but has been too busy of late to concentrate on it. Chris Muller and Hans-Martin did a nice job rearranging the library into a MC packages (see squeakSoruce www.squeakSoruce.com) , and Chris has a separate KryptOn Package that he is actively seeking comments for design review. We started a Cryptography team Development list: http://lists.squeakfoundation.org/mailman/listinfo/cryptography . We have a nice membership but need to promote the group more I would think, and have some more general discussion about direction. We also established a relationship with Dan Ravicher at the software freedom law center. They worked with us while we notified the US Government of an Open Source Cryptography group that allows foreign export of code. This allows US Developers to contribute code without fear of breaking any US laws as long as they do not knowingly export code by way of directly transferring information to a country that is on the US list of terrorist countries. (Posting to our repository is ok) They have also agreed to help us with License Negotiations, and other Squeak Community issues. I would be very happy to have you join our efforts, or even lead this effort if you have time. See our squeakSource cryptography package and wiki site for our team goals. I'm sure we could make better progress with more help! It's really nice to hear from you, I look forward to your participation, Ron Teitelbaum President / Principal Software Engineer US Medical Record Specialists www.USMedRec.com Ron(a)USMedRec.com Squeak Cryptography Team Leader > -----Original Message----- > From: luciano [mailto:luchiano@gmail.com] > Sent: Monday, February 06, 2006 7:25 PM > To: Ron Teitelbaum > Subject: Re: Looking for Cryptography maintainers SHA256 added to Mantis > > Hi Ron, > Carlos Sarraute just brought your mail (quoted below) this to my > attention: http://macos.tuwien.ac.at:9009/596982653.asHtml > > I didn't receive any mail from you, perhaps you sent it to an old mail > account. Let me know if I can help with anything. > > Thanks, > Luciano > > --- > > From: "Ron Teitelbaum" <Ron(a)USMedRec.com> > Date: Sat, 15 Oct 2005 20:55:14 -0400 > Subject: Looking for Cryptography maintainers SHA256 added to Mantis > > Hello All, > > I'm trying to reach the maintainers for Cryptography; I have added SHA256 > to > Mantis bug server. I've sent an email to Luciano Notarfrancesco but have > not received a reply. The package mentions Leandro Caniglia, John > Maloney, > Duane Maxwell, Carlos Sarraute, and Robert Withers. Are any of you > available to discuss this addition? > > Thanks, > > Ron Teitelbaum > President / Principal Software Engineer > US Medical Records Specialists > Ron(a)USMedRec.com

2 2

package structure
by Chris Muller 13 Feb '06

13 Feb '06

I know we've talked about our package structure before but.. As I work through this book, I have some fixes and additions to our Crytography packages. Here is a list of things I plan to post in the coming days: - addition of entropic sources for seed material - addition of the CTR (counter) cipher mode - addition of the "Fortuna" random generator - fix for seriously broken MillerRabin algorithm preventing generation of proper-sized asymmetric keys (i.e., for Diffie-Hellman / ElGamal and maybe RSA too). For the first one "entropic sources for seed material". It individually hashes unpredictable strings from the users environment such as: - current directory - Time millisecondClockValue - World imageForm bits compressToByteArray - SmalltalkImage current vmStatisticsReportString - Sensor mousePoint - etc., etc. and then finally SHA256 hashes the concatentation of all of those hashes. Slow, but totally unpredictable. I've started by implementing SecureRandom class>>#entropicSourcesDo: which is used by SecureRandom class>>#randomSeed. But SecureRandom is in the "CryptographyBase" package, so I can't use SHA1 and SHA256. It seems to me that many crypto primitives are built from other ones. Wouldn't it be easier to have everything back in one package? What are we trying to accomplish here by having them all in separate packages? How should I proceed? Thanks, Chris

3 2

Added SHA256 class>>#blockSize.
by Chris Muller 13 Feb '06

13 Feb '06

I hope you don't mind, I added this method to SHA256. I discovered it was missing when I tried to use HMAC on: SHA256 new I committed Cryptography-SHA256-cmm.4 to the repository, please let me know if you have any questions. - Chris

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Cryptography February 2006