Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

***[Possible UCE]*** FW: P1619 April 16 2004 Minutes -resend for archive

Title: Message
 
-----Original Message-----
From: Clement Kent
Sent: Monday, April 19, 2004 4:24 PM
To: stds-p1619@majordomo.ieee.org
Subject: ***[Possible UCE]*** P1619 April 16 2004 Minutes

Minutes from IEEE P1619 working group meeting, Friday April 16, 2004
Univ. of MD, College Park, MD
 
The meeting was Chaired by Jim Hughes. Minutes were taken by
Clement Kent.
 
Present at some point in the day:
CA Curtis Anderson, Mendocino Software
CK Clement Kent, Kasten Chase
DB Don Beaver, Seagate (phone)
DN Dalit Naor, IBM Haifa (phone)
EZ Erez Zadok, SUNY Stony Brook
FM Fabio Maino, Andiamo/Cisco
JC John Cole, ARL
JH Jim Hughes, STK
JS Julian Satran, IBM
JV John Viega, Secure Software
JW Jim Williams, Emulex
SH Shai Halevi, IBM (phone)
SP Serge Plotkin, Decru  (phone)
 
A quorum of companies was present.
JH moved to approve minutes as published. CK seconded. Approved.
Slides 1 & 2 from IEEE shown re patents.
 
IEEE Patent statement was read.
====================
Discussion re EME patents.
 
SH says IBM has no such patent.
 
Phil Rogaway may have something (UC) resulting from work
preceding his joint efforts with Shai.
 
LRW -Shai does not believe there is anything.
====================
Agenda:
1. Organizational work
2. Key Backup format
3. Object-based storage
4. John Viega, ABL alternative wide block
5. Wide-block format
6. LRW
7. extra byte options (what to do when extra bytes
avail for integrity)
 
 
 
====================
New Actions:
1. JH - send Shai statement on what kind of patent language
we want. SH will send to Rogaway for comments from UC
 
2. JH - Forward document on organizational positions (vice
chair, scty) for vote and posn filling next meeting
 
3. Curtis Anderson -send email to Dalit with suggested
"vendor" prefix format for optional parameters. DONE
 
4. SH - forward EME reference implementation DONE
 
5. SP,DN - prepare a presentation for the next meeting on
OSD versus P1619.
 
6. FM - ask if Cisco can divulge approximate ABL4 performance
specs, and if answer yes, will divulge.
 
7. Suggestions to JV: publish in Crypto, ask an academic
counterpart to investigate and publish on performance
 
8. CK - Add to minutes details of 2 motions, intention to
vote on these next meeting, short description of reasons
for each, circulate. DONE- see below
 
9. Next meeting: ??Wednesday June 9?? Telephone only??
Suggest Apr 30 date to firm this up. Location suggested
is West Point, colocated with IA meetings that week.
 

Motion to adjourn: approved.
============================================
 
Straw Vote (non-binding) motions discussed re AES
key strengths:
 
A) Vendors must implement at least one of the 3 AES
strengths for at least one transform, and 256 is recommended.
 
B) Vendors must implement only AES-256 for at least
one transform.
 
C) Vendors must implement AES 128 and may implement
192 or 256 for at least one transform.
 
Straw poll votes (all people voted, includes double
votes for some companies):
1. A,B,C, people can vote Y/N multiple times:
A: 5Y,4N,
B: 6Y,2N 
C: 3Y,5N (1 abstention on B,C)
 
After this vote, we reduced the straw poll to vote only on A
and B, asking each person to vote yes for only one option:
 
New vote counted by people:
A: 6Y
B: 3Y
Counted by company (JV, DN not voting) 
A: 4Y
B: 3Y
 
A brief summary of the rationales presented:
- Some present favored AES-128 for reasons of economy
(lower gate count at given speed, lower power consumption)
- Some favored AES-256 only since some Top Secret data
requires 256, and it is conservative to  protect long-term
data at the highest level. With sufficient gates, it is as fast as
128 or 192.
- Some favored fewer strengths, to reduce interoperability
issues.
 

==============================================
Key Backup format, Dalit Naor

Dalit's questions:

0) Standard preface text? Dalit will supply example paragraph.
 
a) Scope of key -
 - should units of key scope length be sectors,
 cipherblocks, bytes? Or should the unit be
 defined in the transform document? Consensus:
 use bytes, exile details of application of scope
 to transform documents.
 
b) Where does Tweak live? Agreed in transform documents
 
c) Should EME-1-AES be in? Agreed No.
 
d) XML key scope and format:
 - should key wrap be must or may (vendors must
 implement, users may or may not wrap)
 - add pointer to standard
 - supply schema example for use
 
========================================
Object Storage, Julian Satran.
Discussion:
 
1) OSD may request key for object from KMS, wrapped with a
partition key or similar key shared between KMS and OSD.
The Key backup format may represent such a key exchange format.
In this case the OSD can communicate the key to the encryption
service.
 
2) We can specify a periodicity at which integrity data is to be
added to the data by the OSD or encryptor. Examples would be every
512 bytes, etc. In this case the transform to be used need not
be a wide-block pseudo-integrity tranform. We did not determine
exactly which transforms would be supported in this case.
 
3) Threat models versus topologies should be clarified (what
keys does OSD have, versus the encryptor).
 

=======================================================================
John Viega, ABL
 
GCM = Galois Counter Mode - NIST submitted. in 802.1ae and
ipsec drafts.

Hash iteration: Ri = K x (Ri-1 + Mi)

Shai states GF2^128 multiply is slower than AES but Viega says
it is not. At Cisco they tried it and were able to make it fast
with low gate counts.

On a 512 byte sector ABL4 would do 64 AES-CTR (2 passes of 32 each)
encrypts plus 64 GF multiplies, table optimized.
 
               AES           GF Multiply
ABL4       64              64
LRW       32              32
EME       65              64 multiply by 2 ops

Shai suggests using Naor-Reingold instead of Luby-Rackhoff.
Currently requires 4 keys, but have approach to derive these
from 1 key.

Serge asks for approximate indication of #gates, clock MHz,
throughput.
=======================================================================
EME
Document was reviewed and no changes were recommended.
 
=======================================================================
LRW
Remove multiply by 2, replace with general GF2^128 description.
Fix references indenting.
Remove Must language on 512 wide blocks.
Make key Key strength language same as for EME.
=======================================================================
Extra bytes for integrity:
Wide ranging discussion not captured here. FM will take general
description of some options to T10 in Monterey along with description
of what P1619 is doing. We will return to this topic in future meetings.
For now, our goal is to finalize 512 byte transforms.
 
 
 
****************************************************************************
 
Clement Kent
ckent@kastenchase.com
(905) 238 6900 ext 3237