Celebrating Ada Lovelace Day at Oracle

Lovely infographic including Ada Lovelace Day tweets from many Oracle team members - Enjoy!

GHC13: A Man's Perspective - An Interesting View

I've seen men at the Grace Hopper Celebration of Women in Computing before, but I've never seen anything written by them after attendance.  This week I came across two outstanding blogs written by men about being a man at a female dominated event.

From Jamie Talbot, Is This What It's Like For Women At Every Conference?

From Owyn Richen, Grace Hopper 2013 - A Guy's Perspective:

"I was a little intimidated thinking about being among the minority at the conference, gender-wise, and it made me better understand how a woman might feel in our male-dominated industry. Once I got there, all I really felt was excitement about having the opportunity to learn from leaders in both the academic and industry sectors, who happen to be women."

Update: a third blog was sent my way by Matt Wallaert, Observations from the Land of Amazons:

"And honestly, having dramatically more women than men around actually made me relax too. There was no implicit competition, no being bothered by obnoxious crowds of guys crowded around the sexually attractive women and ignoring the less attractive ones."

These two [update: three] blogs from men that attended this year's GHC really put in perspective what it's like for nearly every woman at a male dominated conference, minus the fear of assault or having their opinions dismissed due to their gender.

These are really thought provoking and worth reading. Also, from these blogs, you get a real sense that this isn't just a "feel good networking event for women" (as I've heard it called by many who have a drastically incorrect impression of the event), but rather an outstanding technical conference that also helps you to grow your soft skills, inspires and raises your confidence as a person in tech.

GHC is one of the most inclusive conferences I've ever been to. You do not have to be a woman to attend, you don't even have to have a strong gender identity at all. The conference also provides FREE child care which really makes it possible for parent's to travel to such an event and not have to struggle to find child care in a strange city.

I missed this year's GHC (first time since 2007), because I was presenting at another conference the week before (ICMC) - but following the twitter feeds and blogs really helped me feel like I was attending virtually. Thank you, Online Communities Committee, for capturing your memories for me.

With Ada Lovelace Day this week, I have to say I continue to be inspired by the work that Anita Borg did to plant the seed to create this amazing community of women that is Systers, Anita Borg Institute for Women in Technology LinkedIn group (nearly 10K strong), Grace Hopper Celebration, Women of Vision Awards... her influence goes on and on and she inspires me nearly every day.

Any other blogs that I've missed? What are you thoughts?

This post syndicated from: Thoughts on security, beer, theater and biking!

Auditions: Join Me in the Lyric Victorian Carolers!

Who doesn't like Christmas Carols? If you do enjoy carols and would like to be a part of a very exciting Lyric opportunity to sing these lovely carols, we would love to have you join us. We are the Lyric Victorian Carolers and are looking for ensemble and quartet members to join this extremely successful caroling group for Lyric Theatre.

We will be singing from the 45+ carols in our repertoire from the tradition to some more contemporary holiday favorites. The events will be throughout the holiday season and range from private parties to various mall and large-scale events. There is no minimum number of engagements required and we will try to accommodate scheduling as best we  can. We realize the holiday time is a busy time for all but bringing the sights and sounds of a Victorian Christmas to our audience is really an extra special gift.

All auditions by appointment. Audition times: (Durations are 10 minutes)

Tuesday  October 8   6:30pm - 8:30pm
Wednesday  October 9  6:30pm - 8:30pm

We need all voice parts. We provide MP3s to help you learn your music.

This is a non-paid opportunity, as with all other Lyric productions. Auditions and rehearsals will be held at the Lyric Theatre Rehearsal Facility, 430 Martin Ave., Santa Clara. Further information about Lyric Theatre and directions to our facility are available on our website: www.lyrictheatre.org.

Please visit the sign up page or call 408-986-9090 and leave a message to schedule an audition appointment. Please allow 48 hours for a response.

Please prepare your favorite Christmas carol and come to the audition with your music, if needed. Please refrain from O Holy Night and Ave Maria for the auditions. We are an a cappella group so minimal accompaniment will be provided. Rehearsals will begin on Tuesday October 15 and run on Tuesday and Thursday nights. Conflict information will be solicited later.

If you aren't the performing type, but would like to see singers at  your church, community gathering, holiday party, wine tasting event, corporate party, etc, please contact us through our website: http://lyrictheatre.org/jl/outreach/caroling.html

Hope to see some of you there!

ICMC: Software in Silicon: Crypto Capable Processors: Slides

Our presentation went really well at the inaugural International Cryptographic Module Conference in Gaithersberg, Maryland last week. I co-presented with Dave Weaver (SPARC Architect) and Wajdi Feghali (Intel Architect).

As per popular demand, please find the slides online:

ICMC: ISO/IEC 19790 Status and Supporting Documents

Presented by Randall Easter, NIST; and Miguel Bagnon, Epoche & Espri.

Mr. Bagnon started out by explaining the structure of ISO, the IEC and SC27 working group.  The ISO standards body looks at  creating market driven standards, getting input from all of the relevant stake holders.  The SC27 focuses on security and privacy opics across 5 working groups.  The SC27 has 48 voting member countries - from Algeria to Uruguay!  There are 19 other observing countries. You can see a very wide representation of continents, countries, cultures and languages.

The WG3 Mission is security evaluations, testing and specification. This covers how to apply the criteria, testing criteria, and administrative procedures in this area.

The process is open to the world (as you can see), drafts are sent out for review by the public before becoming a final international standard.  Please participate if you can, it's the only way to have your opinion counted.

Mr. Easter then dove into ISO 19790, and the related standards: ISO 24759 (test requirements for cryptographic modules), 18367 (algorithm and security mechanisms conformance testing), 17825 (testing methods for the mitigation of non-invasive attack classes against crypto modules) and 30104 (physical security attacks, mitigation techniques and security requirements).

ISO 19790 was first published in 2006 and it was technically equivalent to FIPS 140-2, plus an additional requirements for mitigation of attacks for Level 4.  This standard has been adopted internationally and is being used around the world.

What Mr. Easter had been hoping would happen was that ISO 19790 and FIPS 140-3 would closely track each other, with ISO 19790 picking up all of the changes from FIPS 140-3.  FIPS 140-3 was so delayed, though, that ISO 19790 began to develop independently.

Mr. Easter noticed that there were no validation labs participating in the ISO standard, so he got permission to circulate the draft amongst the labs and to incorporate their comments, as he's the editor of the document.

This document has been adopted by ANSI as a US standard now as well.

At this time, it is not officially recognized by NIST and the US Government.

This is very frustrating to many vendors and labs, because FIPS 140-2 was published in 2001 and it is quite stale (hence the 170 page Implementation Guidance). Technology is changing, the original language in FIPS 140-2 wasn't clear to all, and there seems to be a way out - if only NIST would adopt it.

Until that happens, vendors are stuck implementing to FIPS 140-2.

How can you change this? Call up your NIST representative or friendly CSEC contact and ask for this.

This post syndicated from: Thoughts on security, beer, theater and biking!

ICMC: Key Management Overview

Presenters: Allen Roginsky and Kim Schaffer, NIST.

Key Establishment Methods

Key Establishment Methods in FIS 140-2 cover key agreement, key transport (including encapsulation and wrapping), key generation, key entry (manual, electronic, unprotected media), and key derivation.

The best method to make sure you do this right is to comply with SP 800-56A (CAVP KAS certificate required).

You can also use SP 800-56B, which is vendor affirmed right now. SP 800-56B is IFC based and key confirmation is highly desirable.

Or, you can use non-approved methods that rely on approved validated algorithm components. The shared secret is still computed per SP 800-56A with a CVL certificate. The kdf (key derivation function) then would be aproved (with a CVL certificate) per SP 800-56B and 80-56C.  There was a new version of SP 800-56A released in May 2013 that should help alleviate some of this convoluted cross referencing, and clarify many questions people have had over the last few years.

OR...you can even use non-approved, but allowed implementations.  That is, if your key strengths are consistent with SP 800-131A transition requirements.

Key Transport Modes

Key transport modes can be confusing as well.  Key encapsulation is where keying material is encrypted using asymmetric (public key) algorithm.  Key Wrapping, though, is where the keying material is encrypted suing symmetric algorithms. Both commonly provide integrity checks.

Approved methods would be an approved IFC based key encapsulation scheme as in SP 800-56B, key wrapping schemes (AES or 3DES based) as per PS 80038F, AES based authentication encryption m odes permitted in SP 800-38F, or as per SP 800-56A, a DLC-based key agreement scheme together with a key wrapping algorithm.

Any key encapsulation scheme employing an IFC based methodology that uses key lengths specified in SP 800-131A as acceptable or (through 2013) deprecated.   When AES or 3DES are used for wrapping, a CAVP validation of the algorithm is required.

Key Generation Methods

People often mistakenly believe that because they are using a good RNG, that they must be doing the right thing for key generation... not always the case!  You still need to follow SP 800-133 and IG 7.8 (Implementation Guidance).

The vendor needs to identify the method used and account for the resulting length and strength of the generated keys. This is about the generation of a symmetric algorithm key or a seed for generating an asymmetric algorithm key; the the generation of an asymmetric algorithm domain parameters and RSA keys.  See IG 7.8 and the future versioin of SP 800-90A.

You can use SP 800-132 for password-based key generation for storage applications only.

Key Entry

Implementation Guidance (IG) 7.7 provides examples explaining the FIPS 140-2 requirements. Key entry/output via the GPC internal path is generally N/A.  Key establishment over the unprotected media requires protection.  Split knowledge entry for manually distributed keys at Levels 3 and .

Key Derivation

When you're deriving a key - it's coming from something else. If you're deriving from a shared secret (per SP 800-135rev1), that includes the following protocols and their key derivation function are included: IKE (versions 1 and 2) , TLS (1.0->1.2), ANSI X9.42 and X9.63, SSH, SRTP, SNMP and TPM.  You can also drive from other keys, which is covered by  SP 800-108 - which also includes IEEE 802.11i key derivation functions (IG 7.2).



 This post syndicated from: Thoughts on security, beer, theater and biking!

ICMC: The Upcoming Transition to New Algorithms and Key Sizes

Presented by Allen Roginsky, Kim Schaffer, NIST.

There are major things we need to be concerned about – we need to move from old, less secure algorithms to the new ones. This includes the transition to 112-bit strong crypto and closing certain loopholes in old standards

The algorithms will fall into the following classes:

• Acceptable (no known risks of use)
• Deprecated (you can use it, but you are accepting risk by doing so)
• This is a temporary state
• Restricted (deprecated and some additional restrictions apply) 
• Legacy-Use (may only be usd to process already-protected information) 
• Disallowed (may not be used at all)

And of course, these classifications can change at any time. As you all know, the crypto algorithm arena is ever changing.  I asked a question about the distinction between Legacy-Use and disallowed.  It seems to me that you might find some old data laying around that you’ll need to decrypt at a later date.  Mr. Roginsky noted that they didn’t really cover this when they did the DES transition, and you might be okay because decrypting is not really “protecting” data.

When we get to January 1, 2014, 112-bit strength is required.  Two-key 3DES is restricted through 2015. Digital signatures are deprecated though 2013 if they aren’t strong enough.   This is an example where you could continue to use them for verification under “Legacy-Use” when we reach 2014.

Non SP-800-90A RNGs are disallowed for use after 2015 – you won’t even be able to submit a test report after December 31, 2013 if you don’t have an SP-800-90A RNG.

There is a new document everyone will want to review: SP 800-38 – it explains the use of AES and 2Des for key wrapping.

SHA-224, 256, 384, 512 are all approved for all algorithms. SHA-1 is okay, expect for digital signature generation. There are other changes around MACs and key derivation.

We’ll also be transitioning from FIPS 186-2 to FIPS 186-3/4.  Conformane to 186-2 can be tested through 2013.  Already validated implementations will remain valid, subject to the key strength requirements.  Only certain functions (such as parameter validation, public key validation and signature verification) will be tested for 186-2 compliance after 2013.  What this really means is that some key sizes are gone” after 2013: RSA can only use 2048 and 3072 keys.

Make sure you also read Implementation Guidance (IG) 7.12: RSA signature keys need to be generated as in FIPS 186-3 or X9.31.

The deadlines are coming up – don’t delay!

 This post syndicated from: Thoughts on security, beer, theater and biking!