Cryptography December 2006

cryptography@lists.squeakfoundation.org

7 participants
10 discussions

Help with Processor Scheduling
by Ron Teitelbaum 01 Jan '07

01 Jan '07

Hi All, I was wondering if someone could help me answer a processor scheduling question. I'm running a process to test SSL memory. The data is received by a process running in a thread priority 40. The server is running priority 70. (both in the same image). There is one thread started as dataHandler for each send. When I run normally everything works fine. I send data and the dataHandler process picks it up and closes down. I'm seeing one send and about one receive before another send. When it's all done everything sent was received. The problem is that when I leave squeak and click on any other application, what I see is lots of sends but only rarely a receive. Then the application usually freezes up and has lots and lots of sockets open. Can someone explain to me why a test running and processes scheduled would act so differently if I click on another application? I tried to look at Processor activePriority hoping that since UI was running at 40 that maybe active priority was raised when Squeak was not the top most application. It appeared to stay at 40. Thanks for your help and any suggestions on how to diagnose this problem. Ron Teitelbaum

2 3

Fix to RandomPool
by Ron Teitelbaum 21 Dec '06

21 Dec '06

I made the following change RandomPool >> stir | cipher block | Transcript cr; show: 'stir'. cipher _ (TripleDES key: key) cbc. cipher initialVector: (pool copyFrom: pool size - TripleDES blockSize + 1 to: pool size). 1 to: pool size - TripleDES blockSize + 1 by: TripleDES blockSize do: [ :startIndex | block _ pool copyFrom: startIndex to: startIndex + TripleDES blockSize - 1. cipher encryptBlock: block. pool replaceFrom: startIndex to: startIndex + TripleDES blockSize - 1 with: block] I had to add the + 1 for setting the initalVector, I was getting 9 bytes. Ron Teitelbaum

2 2

Cryptography-RandomAndPrime-cmm.7
by Chris Muller 16 Dec '06

16 Dec '06

Until we have a robust accumulator, we now have RandomGenerator>>#generateKey to seed our Randoms upon first usage every image start. This method generates 32 random bytes by enumerating a variety of hard-to-guess information, using feedback and chaining all prior values, making it basically impossible to guess. So even quitting (without saving) and restarting the same image, you get different seeds every time.

1 0

[ANN] Fortuna and RandomGenerator
by Chris Muller 15 Dec '06

15 Dec '06

I have just posted the following packages: - Cryptography-RandomAndPrime-cmm.3 - Cryptography-Core-cmm.18 RandomAndPrime refactors SecureRandom into the following hierarchy: RandomGenerator SecureRandom with a short, well-considered API. RandomGenerator provides: nextBits:, nextBytes:, nextFrom:to:, and nextInt: Subclasses must implement nextBits: and nextBytes:. With these new versions, you may then load - Fortuna-cmm.5 which adds a Fortuna subclass exactly as specified by Practical Cryptography. The changes to Cryptography-Core include: - implemented BlockCipherMode>>#destroy to avoid potential leakage. - minor improvements to CTR mode. - changed HashFunction>>#doubleHashMessage: to answer a ByteArray (LSB first) intead of an Integer.

1 0

Developing in what image/version/build?
by Cerebus 03 Dec '06

03 Dec '06

With the plethora of Squeak images, versions, builds, whatever, I'm a little confused as to picking the best environment. Currently I've been working in the 3.9-8 VM with the 3.9-final-7067 image, but some things don't seem to work right. -- Tim

3 6

RE: Developing in what image/version/build?
by Chris Muller 03 Dec '06

03 Dec '06

> That's very interesting, I'm using 3.9 fulltime and I don't have any of the > problems you are experiencing. Huh? Ron, just open a 3.9g-7061 image, what you get from downloading from link at the top of squeak.org, and you have the problems I describe. Problem #1: > Monticello packages with changes in the base image Just open a Monticello browser, see * Morphic and * Multilingual? Problem #2: > lists jumping around upon selection Now just scroll the package list down about 10 and then select a package near the top of the window. It not jumps straight back to the top, unready for my right-click after I've just left-clicked it. Lockups happened for me all the time without Seaside; in fact I never was even able to get my few dev tools in there without constant lockups. I tried to track it down but can't remember now, ran out of time. > It was the seaside code for comet. > Bumping up the priority fixed the problem. I guess I missed this, can you explain or do you have a link?

2 1

Islands Discussion
by Ron Teitelbaum 03 Dec '06

03 Dec '06

Has anyone had the chance to review Islands in any detail? Lex has joined the team mailing list and may be able to answer some questions. I would be interested in everyone's thoughts. Also I'm sorry I haven't had more time to spend on it, I will try to do more Mid December. I have a big meeting coming up that is taking a lot of my time. Ron

2 2

Todays Meeting update
by Ron Teitelbaum 01 Dec '06

01 Dec '06

Hi All, I had a very nice meeting with someone that was responsible for CC and FIPS at Mozilla. I left the meeting with a better understanding of what we need to do. Here are my notes: FIPS 140-2 was originally developed as a hardware specification. Many of the requirements for FIPS 140-2 software validation still resemble a hardware implementation. The basics of 140-2 are: 1) Module validation: Do the modules do what they are supposed to do. There are a number of other validations for specific algorithms that we may want to do. 2) FIPS Mode of Operation: Which requires that a user authenticate to the module before it performs any operations. This is like a smartcard or some such hardware implementation. The Trusted Computing Base would also do a self check on startUp. 3) low level / high level algorithm separation: Make sure that the algorithms are properly separated with in the OSI levels. 4) Since we are software and potentially multiuser we would need FIPS 140-2 level 2 validation. The most difficult part of FIPS is the security document. We may want to review openSSL and integrate that or NSS into squeak for people that have to have an FIPS validated system. This would remove our need to be validated, and shift our job to interpreting and implementing external modules properly. OpenSSL solved the problem of code isolation, since they allow both separate lib calls and imbedding the library into your application, by setting up a chain of custody which defines how to verify the code has not changed from Authors to end users. This doesn't seem to prevent malware from changing bytes but this may not be required for FIPS validation. We should look more closely at OpenSSL's documentation. Documentation of all modules is also needed. Common Criteria. It seems to me that there is little use for us to proceed with CC. CC is more like a system evaluation. They even call it a system evaluation. The evaluation has different levels we would probably want 2 or 3 but in order to have something to validate we would actually need to write a system. An example of something that would be validated is an Operating System. The operating system requires user authentication, Access control like ACL's, resource partitioning ... In this example if the user is required to enter a password and the operating system says it needs n letters, can only be entered 3 times before being inactivated, and needs to be changed montly. Then this would be part of the Protection Profile that is already written for operating systems. If there is no current Protection Profile for your system you can either write you own, and submit it for consideration of all systems like yours or you can write a Security Target Document which explains just what your system is doing. Plus there are the controls over the development environment and library. This "what" your system is doing is what would be evaluated. We may want to review the Java CC evaluation but it seems to me that we do not have standard authentication, acl's ... We may want to write some of those pieces for people to use, but until we have them we should probably be focusing on FIPS 140-2. I'm sorry I didn't understand the distinction earlier. Also CC validation runs around US$200K. FIPS can be between US$40K - US$100K I'm told that if we want to do CC then we should look into foreign labs since CC is international and a validation from say the EU would be valid in the US. Apparently Oracle saved a bundle doing this. So I'm scheduling a follow up meeting with someone else that I was introduced too that does is working with a lab to do FIPS Validation for NSS. My interest is in how we can get enough of a direction to get things moving on our own, suggestions on selecting a lab, and what we can expect. There is nothing like practical experience. I'm considering forming our own Foundation and doing some fundraising to cover our costs, so we will need to show longevity and commitment to encourage investment. Until that time we need to make sure we are on the right path. Comments are welcome, Ron Teitelbaum President / Principal Software Engineer US Medical Record Specialists Ron(a)USMedRec.com Squeak Cryptography Team Leader

3 10

NSS Meeting
by Ron Teitelbaum 01 Dec '06

01 Dec '06

Hello all, Ok I just finished my NSS Meeting and here is what I learned. The testing labs are not allowed to work as a consultant. If you feel that you need a consultant then you can hire a second lab to help. But the labs do a pretty good job of documenting why things fail so if you don't mind the iterative work and are not looking to save time by having a consultant then one lab is fine. You could also hire a NIST consultant that is not connected with a lab. The best thing to do is run thorough the 140 standard and make your best guess as to the requirements. This is especially helpful when you have your initial meeting with the labs. Many labs will offer a very long 2 day meeting where they go over all of the NIST requirements, with you. This is a good chance to ask questions for example if you have a solution to a requirement you could ask at that time whether or not your solution meets the requirements. Also this is a good time to identify anything that you missed. Sounds like a potential Squeak Cryptography Conference candidate, we'll have to work out the details when the time comes. Labs usually offer a fixed fee for validation but we should be careful not to sign with a lab that has a fixed term. The first phase, the validation of the algorithms takes about 3 months to complete. The second phase the crypt module part takes about 6 months. The final phase takes 3 months so any delay at all could easily send you over the 12 month that is offered by some labs. NSS first pass was 18months. This last round was closer but will probably go over 12 months. The current NSS module is not validated. They have passed the lab part but are waiting on NIST for the final validation. I learned more about the second phase. The second phase includes about 100 questions that need to be answered. These answers are shared with the lab only but it takes a lot of documentation to complete it. They ask questions like how do you protect sensitive data, how do you ensure read and write file protection. I also learned a few answers. The external crypto library can be secured using a CC evaluated operating system. For example if our security document specified that when the file is installed the operating system sets read and write attributes to the user then as long as the OS is CC evaluated that meets NIST validation. Also the requirements at NIST are not as stringent as you might think. There are a number of areas of real security concern that are not addressed by NIST. For example the protection of private keys. NIST requires wiping of memory after the key is used but does not mention encrypting the value in memory or preventing swapping. NIST can only review the Security policy and the Test report of the lab. So the security policy is very important. If you spend more time on the security policy, make it easy to use, then NIST will have an easier time and may be able to turn your validation around faster. The answers to your questions and your source code is not available to the NIST during the final review. If you have any difficulty with the security policy or need answers on how to solve certain requirements then checking other open source security policies can definitely help. Also since there are a number of OS crypto modules using their test examples, comparing input and output, and structure of the tests may help you to understand the tests better. In there experience if the library is being used the implementation is probably correct, most errors are actually errors in understanding or implementing the test. There is an interesting dynamic working with Labs. It starts off as a pseudo adversarial relationship. The lab works against you making you prove your code. But once the Lab passes you, that dynamic changes and you become a team working to get the final validation. The cost for the labs for a full multipurpose validation on 7 OS's ran around US50k. I'm expecting information about implementing and using the NSS validated crypto module for Squeak. Comments are welcome, Ron Teitelbaum President / Principal Software Engineer US Medical Record Specialists Ron(a)USMedRec.com Squeak Cryptography Team Leader

1 0

Re: [Cryptography Team] Developing in what image/version/build?
by Chris Muller 01 Dec '06

01 Dec '06

There's plenty about 3.9 that is less than acceptable. I've moved back to 3.8 my forward development until 3.9 improves. I recommend 3.8 for new Squeakers. 3.9 has some real usability issues that turn off new and old users alike; like lists jumping around upon selection is just one of many. 3.8 offers a cleaner start, less confusing, and you don't have Monticello packages with changes in the base image. The uninterruptable image lockups though, all on their own, were plenty enough for me to switch back. 3.9 has that new window look, but you can get that in 3.8 real easy if you want: http://map.squeak.org/package/3f07c64c-e22f-42ef-91e1-40c7e0de9185

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Cryptography December 2006