Cryptography July 2006

cryptography@lists.squeakfoundation.org

9 participants
14 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

Suggestions for C++ or DLL code
by Ron Teitelbaum 01 Aug '06

01 Aug '06

Hello all, I'm currently working on a TLS / SSL implementation and on windows I am planning to support the Certificate Store that is built in. This requires me to use the CryptoAPI dlls. The code is complex and it uses a number of header files and many steps. I built some C++ code that does what I'm looking for so now I would like to incorporate this into Squeak. I'd assumed that FFI was like DDL/C connect in VW but that's not what I'm seeing. So my question is: What is the best way to get this working? Should I hack away at FFI and support the api directly, and is that even possible? Should I create DLL's to call and use them with FFI, or should I compile some sort of plugins? My preference would be to call the api directly without having to create dll's, duplicating my C++ code in Smalltalk if possible. Some direction and comparisons of different options would be very helpful. Thank you for your help! Ron Teitelbaum

6 11

RE: Suggestions for C++ or DLL code
by Ron Teitelbaum 31 Jul '06

31 Jul '06

Andreas, I'm supporting the certificate store of windows. I will be reading and writing certificates to be used for SSL/TLS. The reason for this is to simplify some of the tasks needed to support SSL and to support what is already perceived to be a safe storage method in windows. (I am also thinking about supporting LDAP for storage instead but that is down the road, first things first) As for the VW dll/c connect code. I found the ability to set up libs and header files and automatically generate code very useful. Looking at the FFI kernel it appears that the pieces are there for me to assemble manually, which I why I asked the question if it is possible. What concerns me most is having to dissect the 5 or 6 very large header files that are needed to support the few api calls that are made. Are there some good examples of more complex FFI calls and structures, or easier ways to support many different required header files? I haven't downloaded the VMMaker or looked at slang, do you suggest I look at that first before deciding on which path to take? Thanks for you help, Ron Teitelbaum > -----Original Message----- > From: squeak-dev-bounces(a)lists.squeakfoundation.org [mailto:squeak-dev- > bounces(a)lists.squeakfoundation.org] On Behalf Of Andreas Raab > Sent: Sunday, July 30, 2006 4:07 AM > To: The general-purpose Squeak developers list > Subject: Re: Suggestions for C++ or DLL code > > Ron Teitelbaum wrote: > > I'd assumed that FFI was like DDL/C connect in VW but that's not what > > I'm seeing. So my question is: What is the best way to get this > > working? > > My first question is: What is it that you're trying to get working? My > second one: In which way is the FFI not like DLL/C connect in VW and why > would that matter? > > Cheers, > - Andreas >

1 0

OpenSSL FIPS Revoked - Should we continue to try and certifiy Squeak?
by Ron Teitelbaum 20 Jul '06

20 Jul '06

All, The only response I received about our proposal to try to get certified was from Andreas who said he'd send it off to the Croquet board. After reading this article I really believe that we should try to get certified, if for no other reason then to help the open source community in general. Is there still an interest in this group to go through this process? If so I will undertake the process of screening all certified labs to find the strongest lab that understands the difficulty and intricacies of open source. Please respond back and let me know your support for the project and your willingness to participate, or any other comments. I really think the process will be very beneficial and the challenge you have to admit is a good one. Thanks! -Ron Teitelbaum Security validation of OpenSSL encryption tool uncertain Jaikumar Vijayan July 19, 2006 (Computerworld) A joint U.S. and Canadian organization that certifies encryption tools for use by federal government agencies has suspended its validation of OpenSSL cryptographic technology for the second time in less than six months. The decision means that government agencies can't purchase the open-source tool for the time being, although those that have already done so will still be allowed to use it. OpenSSL is an open-source implementation of the Secure Sockets Layer (SSL) and Transport Layer security protocols. It is widely used to encrypt and decrypt data on the Internet. The decision to suspend validation of the tool came just two days after the group doing the validation, the Cryptographic Module Validation Program (CMVP) at the National Institute of Standards and Technology (NIST), had taken the harsher step of revoking the tool entirely. It backed away from that decision and opted for a suspension of the process instead. News of the rapid changes to the validation effort drew criticism from the Hattiesburg, Miss.-based Open Source Software Institute (OSSI), a nonprofit group trying to get the OpenSSL encryption module validated for use in government. John Weathersby, OSSI's executive director, today alleged that the move appears to have been influenced by vendors of proprietary technologies that stand to lose a lucrative market if an open-source alternative is certified. "There are some vendors fighting like hell to make this die, and I can see why," said Weathersby. "What's going on is the question of the day. This is not a technology issue; this is a political issue." OpenSSL is supported on several major operating systems, including many flavors of Unix, Apple Computer Inc.'s Mac OS X and Microsoft Corp.'s Windows. OpenSSL received its precedent-setting validation in January from the CMVP, which is charged with validating and certifying that cryptographic tools sold to government agencies meet the requirements of the Federal Information Processing Standard (FIPS) Publication 140-2. The CMVP was established by NIST in the U.S. and the Communications Security Establishment of the Canadian government. A validated OpenSSL tool would allow vendors of operating systems, Web browsers and other software products such as e-mail to include a free FIPS 140-compliant cryptographic module. The OpenSSL FIPS 140-2 validation effort is sponsored by the Defense Medical Logistics Standard Support (DMLSS) program, which provides medical logistics support to the U.S. Department of Defense. Currently, agencies looking for encryption capabilities spend hundreds of thousands of dollars -- and in some cases, millions of dollars -- licensing proprietary cryptographic tools that are certified according to FIPS 140. Since January, however, the validation for Open SSL has been revoked and reinstated twice, Weathersby said. The first revocation happened in January, barely four days after OpenSSL was first validated by CMVP. It was awarded a FIPS 140-2 validation again in March after some changes were made to the module. On Friday, OSSI was told that the validation had again been revoked, Weathersby said. That changed yesterday, when the organization learned that the OpenSSL certificate had been incorrectly "revoked" and is now instead "not available," he said. That means that the OpenSSL cryptographic module can no longer be bought by government agencies, although it can be used by those that already have it. NIST, in an e-mailed statement, confirmed the "not-available" status but offered no reasons for it. "However, if noncompliance is discovered in a module after it has been validated, and based on a risk assessment it is deemed to be critical, the CMVP will advise all federal agencies to cease using the affected module," NIST said. A representative for Domus IT Security Laboratory, the Ottawa-based company that is evaluating products for FIPS 140 compliance, referred all questions to the CMVP. The continuing uncertainly about the status of OpenSSL is sure to prolong what has been a multiyear effort to certify the tool. Much of the delay resulted from a continuing series of tweaks OSSI was required to make to the cryptographic module at the request of the CMVP, said Steve Marquess, validation project manager at OSSI. Part of the problem stems from the fact that the FIPS requirements were written for hardware-based encryption tools while OpenSSL is software-based. As a result, mapping FIPS' requirements to OpenSSL has been challenging, Marquess said. Vendors of commercial products have also raised a constant stream of technology-related questions that have proved time-consuming to address. "There have been some commercial interests who are unhappy with open-source validation like this," Marquess said. "One of them has been working for several years to challenge multiple aspects of what we are trying to do," he said without naming the vendor. One of the results is that the requirements for OpenSSL to get FIPS 140-2 validation has keeps changing, he said. "One of our frustrations through this whole ordeal is pinning down the requirements in concrete technical terms," he said. "The requirements keep changing on us all the time." George Adams, the president and CEO of SSH Communications Security Inc., a Wellesley, Mass.-based vendor of encryption products, said that concerns about the use of OpenSSL in government environments are valid. As an open-source tool, OpenSSL is subject to constant changes that would invalidate its certification on a regular basis, he said. For instance, any changes made to the source or linked library in the cryptographic module will create a nonvalidated module, he said. Similarly, any additional cryptography outside of the validated module would need to be tested and validated. Marquess dismissed such concerns. He said that the security policy associated with OpenSSL guarantees that the source code used to generate the cryptographic module is unmodified at all times.

2 2

DES Plugin Secure?
by Ron Teitelbaum 17 Jul '06

17 Jul '06

Chris, I just tried to use your SecureRandom for my SSL implementation and found out I needed the DESPlugin. I found it and everything worked fine, but I was reminded by your previous comment about there being a potential security issue for the communication between Smalltalk and the external black box (in this case the dll). I also noticed the comments about how slow the processing would be if the code was implemented in Smalltalk. So two questions, 1) Do you feel the same way about the DESPlugin being insecure? 2) Do you believe that a native implementation would be too slow? Ron Teitelbaum

2 2

Re: OpenSSL, Stunnel
by Chris Muller 13 Jul '06

13 Jul '06

> Does anyone have any thoughts about the benefits and drawbacks of > having the > cryptographic code be an external black box? Are there greater > benefits to > our having implemented our own code, for education and flexibility . > ? > Personally I would prefer having the code be in squeak, but I thought > the > question worth asking. Should we do both? I think both is good. Public black-box implementations are good for those who just want to be more secure and not have to think about it. These are much more hacked upon which is good for scrutiny, but bad when problems are found. FYI, someone sent me this "advisory" claiming an exposure to the RNG used by TLS/SSL key generation. http://www.gutterman.net/publications/GuttermanPinkasReinman2006.pdf OTOH, I very much want to _understand_ the security, the best way for me to do that is to get my hands dirty with our own code. I think understanding the why's goes far toward being able to make a secure system. It also seems less likely simpler, less-popular protocols would, let alone could, be hacked since hackers probably want the glory of breaking the "big" ones.. But this is a foolish thought to have.. :) - Chris PS - One more problem with "external" black-box is its externality. Assuming you trust the black box, you still have to release sensitive information into the communication-pipes of the OS to get it to the black box.. With internal security, The attacker has to hack the memory of the image, because no sensitive information ever leaves the image.

1 0

Squeak FIPS 140-2 level 2 certification
by Ron Teitelbaum 13 Jul '06

13 Jul '06

All, I've just finished meeting with a testing lab concerning Squeak FIPS 140-2 level 2 cryptographic certification. I would like to share the results of that meeting. Background: OpenSSL has received FIPS 140-2 certification. The fact that an open source project has received certification of their cryptographic module opens the door, in my opinion, for others to do the same. We have an opportunity to learn from their mistakes and success. Having the certification does a lot for our community. Having the certification opens the door for government agencies to use squeak, it allows businesses that work with government to use squeak, and it allows businesses that have high security requirements (which today with the advent of Sarbanes/Oxley in the US means all public companies, or with HIPAA all medical companies) to use squeak. Also we should consider the effects having the certification will have on using Croquet for secure collaboration over insecure networks like the internet. Plus it would help to generate some publicity. Having the certification is not the only way to go. Of course secure networking can be accomplished with other means, and there is a lot that the cryptography group can do to help make that easier for the community to accomplish. There are benefits to both paths that I would like to point out. Having our own libraries written in Smalltalk enhances our ability to educate developers on cryptology. It allows for more flexibility and creativity for supporting higher level protocols like SSL/TLS, SFTP, S-Mime... . Our certification may help to attract a wider security audience, developers, and contributors to Squeak. Using an external certified library instead of an internal squeak library allows us to focus on delivering Crytographic software and less on the cryptology itself. Using OpenSSL allows us to leverage their experience to enhance our software and leaves the onus and costs of certification to them. Meeting Summary: I met with SAIC which is a US Government approved testing lab, in Columbia Maryland. We discussed the following: Can a Smalltalk cryptographic library be isolated enough to allow developers to use the FIPS 140-2 certification to develop software that would also be considered FIPS 140-2 certified? The answer to this question is not simple and will have to be addressed in the initial assessment, the security policy documentation, the testing process, and by the government in its approval. In order for software developed from our certified squeak library to be considered FIPS 140-2 certified it must be able to show that it is using the cryptographic library unmodified, that the approved library was loaded and that the library is not modifiable. There are a number of ways that this can be accomplished, but none of them are simple. (My first thought was to identify and sign our packages and to change the VM to check the signature on startup and to not allow for changes to signed code. This functionality of signing packages may be useful regardless of our decision to pursue certification). What would be required from the cryptography team to get certification? We would have to implement all the standard tests and show that they all pass. We would have to write a security policy (we can use the OpenSSL security policy as a starting point). We would have to work with the lab to prove our code can be isolated, and make changes as required. Is additional padding in cipher text on a standard test considered a passing test? (This question is for the cryptography team) Standard tests are evaluated individually, but additional padding is usually disregarded when validating an algorithm. Additional padding can be added and still pass. How long will the process take? The lab offers an initial assessment which can be used to identify gaps and to help us plan our security policy. The assessment takes about 10-14 days to complete. At the end of the assessment we receive a detailed assessment report. The lab can write the security policy for us, they can also suggest outside consultants, or this is something that we could decide to do ourselves. The security policy will take several months to complete. The lab testing itself along with government communications and adjustments will take between 1 to 4 months to complete The Government certification itself will take between 8 to 12 months after lab testing is complete to get final approval. How much will all this cost? The costs are considerable. If we do most of the work ourselves we can get testing alone for USD $25K. If we start with an initial assessment and let the lab do the documentation it will cost USD $75K. Next Steps: There are no real next steps for now except to discuss if this is important enough for the community to pursue. Certification is a goal that has been identified by the cryptography team, but we can not accomplish this alone. Broader community support will be needed to get it done. Please give me your opinion. I hope that I've given you enough information for you to comment, if not please feel free to ask questions. Thank you, Ron Teitelbaum President / Principal Software Engineer US Medical Record Specialists Ron(a)USMedRec.com Squeak Cryptography Team Leader

1 0

OpenSSL, Stunnel
by Ron Teitelbaum 13 Jul '06

13 Jul '06

Hello all, I've been looking into FIPS but couldn't help falling over the Squeak Pluggin for OpenSSL and Stunnel. https://lists.wisc.edu/read/messages?id=181840 https://lists.wisc.edu/read/messages?id=183375 I haven't tried them yet but was wondering if anyone else has. Does it make sense to move forward with our own FIPS certification, or would it make sense to tightly integrate both openSSL and Stunnel into squeak instead? Does anyone have any thoughts about the benefits and drawbacks of having the cryptographic code be an external black box? Are there greater benefits to our having implemented our own code, for education and flexibility . ? Personally I would prefer having the code be in squeak, but I thought the question worth asking. Should we do both? Thoughts? Ron Teitelbaum Squeak Cryptography Team Leader

3 2

FIPS 140-2 Certification Inquires
by Ron Teitelbaum 12 Jul '06

12 Jul '06

All, I just wanted to let everyone know that I've started looking into the FIPS 140-2 Certification. I've started the search for a testing lab. My first call is with SAIC to get more information. I chose them primarily because they are local to me. If anyone has suggestions, questions they want answered, or people or other labs they suggest that I contact please let me know. I will keep you updated on our progress. Ron Teitelbaum Squeak Cryptography Team Leader

1 0

block-based cipher padding
by Ron Teitelbaum 11 Jul '06

11 Jul '06

Hi Chris, I've finally figured out what was going wrong with some of my CBC tests. I have some more questions about padding. The test: Case #3: Encrypting 48 bytes (3 blocks) using AES-CBC with 128-bit key Key : 0x6c3ea0477630ce21a2ce334aa746c2cd IV : 0xc782dc4c098c66cbd9cd27d825682c81 Plaintext : This is a 48-byte message (exactly 3 AES blocks) Ciphertext: 0xd0a02b3836451753d493665d33f0e886 2dea54cdb293abc7506939276772f8d5 021c19216bad525c8579695d83ba2684 Is returning the value: 'D0A02B3836451753D493665D33F0E8862DEA54CDB293ABC7506939276772F8D5021C19216BA D525C8579695D83BA2684D248B3E0F2388C137102846EB06272FF' which is correct except for the padding. Since we are using the padding and it will be removed in our system should this be considered a passing test? My guess is yes but if we send these encrypted values to other systems will they know how to un-pad and decrypt the cipherText? In other words, how widely adopted is Schneier's and Ferguson's padding suggestion? Should we enable a switch to allow developers to turn this off? Ron Teitelbaum President / Principal Software Developer US Medical Record Specialists Ron(a)USMedRec.com Squeak Cryptography Team Leader

2 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Cryptography July 2006