about the
Seagate experience, and also what you can see from the Cisco router
products, ciphertext visibility and speed of operation are
important deciding factors. Where the line is drawn is not clear -
would hardware assisted IPsec over Firewire/1394 at 400Mbps be OK?
Regards,
Gary
james hu
I am truly saddened by this event on many levels.
I want to reiterate that anyone using this email reflector to
publicly besmirch the reputation of any other member of this group
will not be tolerated.
On May 29, 2006, at 9:46 AM, [EMAIL PROTECTED] wrote:
Publishing email addresses looks li
I believe that I understand this and suggest this is not a case of
grandma writing her keys to the disk, but is a concerted effort of
someone to write K2 to the disk (without knowing the value of K2 or
this would be silly) two times with understandable modification. This
trivially leaks K2.
Jon Kelsey is here at the confence and I will talk to him personally.
. Original Message ...
On Sat, 27 May 2006 09:16:25 -0400 "Cole, John (Civ, ARL/CISD)" <[EMAIL
PROTECTED]> wrote:
>Matt,
>
>I'll ask privately. It is possible that they (a) don't have a good answer or
>(b) they're b
Can we not take care of this in the glossary? If Elliott did not
suggest this, who did?
On May 26, 2006, at 10:17 AM, Matt Ball wrote:
Here is a correction to the minutes from Rob Elliott. Please let me
know if there are any other corrections.
-Matt
-Original Message-
From: Elliott
PROTECTED] wrote:
All IPSEC routers would fall into this requirement.
Could you explain it a little bit more? It sounds like a serious
issue.
Original Message
Subject: Re: Next P1619/1619.1 Meeting -> Discussion Doc D0.7
From: james hughes <[EMAIL PROTECTED]>
Date:
Let me find out. ThanksjimOn May 26, 2006, at 1:48 PM, Matt Ball wrote: FYI: Here are the e-mail messages I sent to NIST concerning key derivation. So far, I have not received any responses. Is there anyone else in the IEEE 1619.1 work group who has contacts in NIST and could help drive this iss
ittle
bit of trust involved.
Don
james hughes <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
No Phone Info Available
05/26/2006 07:55 AM
To
Steven Sletten <[EMAIL PROTECTED]>
cc
james hughes <[EMAIL PROTECTED]>, Curtis Anderson
<[EMAIL PROTECTED]>, [EMAIL PROTEC
decrypted using the algorithm specified in the ALGORITHM INDEX
field and the key provided in the KEY field.
Steve Sletten
james hughes wrote:
That in itself can be considered access control.
So it is the reading of the ciphertext that needs to be
restricted.. This does not say anything about
en "just say no".
Thanks,
Curtis
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of james hughes
Sent: Thursday, May 25, 2006 9:06 AM
To: [EMAIL PROTECTED]
Cc: james hughes; Gary Calder; Gideon Avida; [EMAIL PROTECTED];
Landon Noll; Serge Plotkin; S
Don
james hughes <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
No Phone Info Available
05/24/2006 10:57 PM
To
Gary Calder <[EMAIL PROTECTED]>, Gideon Avida <[EMAIL PROTECTED]>,
Landon Noll <[EMAIL PROTECTED]>
cc
james hughes <[EMAIL PROTECTED]>, [EMAIL
e the US and UK/EU and other Wasenaar signatories seem to be
reasonably aligned in the export policy vis-a-vis encryption
products, things are still obviously very country dependent for
granting of export licenses and also imports.
I hope at least this gives the insomniacs amongst you some
On May 23, 2006, at 11:58 AM, [EMAIL PROTECTED] wrote:
Thanks, Gary, for you very thorough review!
I am not a lawyer, either, not even a native English speaker, so I
have
not attempted to decipher the huge amount of information you link
to. I
rely on the judgment of my colleagues, who went
All:
Matt (Quantum) is providing the bridge at 1-800-668-7083 or
719-536-6600, meeting ID 5766 and online at
https://mponline.quantum.com/join.asp?5766
Fabio will not be able to take notes today, so we will be looking for
an alternative secretary for this meeting.
Remember, withou
er? I cannot stay
on the call until 6pm and I would like to participate in the entire
1619.1
discussion. (Also, I believe that the work on 1619.1 is currently
more
urgent, since we already sent 1619 to IEEE.)
-- Shai
On Wed, 3 May 2006 07:43 james hughes wrote:
Seems like Tuesday works for
I would like some references to the claims in the introduction. My
reason for asking about such is that it is important that we (IEEE)
standardize what is right, not what is politically in vogue at a
moment in history. The I in IEEE is for International. Additionally,
I am interested in whi
Here you are: D06. I still hope for any kind of comments.
Laszlo
Original Message ----
Subject: Re: Next P1619/1619.1 Meeting
From: james hughes <[EMAIL PROTECTED]>
Date: Wed, May 03, 2006 10:43 am
To: [EMAIL PROTECTED]
Cc: james hughes <[EMAIL PROTECTED]>, [EMAIL PROTECTED], D
I am worried about the discussion of 6.2.3... This seems to be
slightly incorrect. The text "IV-collision between any pair of IVs
generated by the VB-device within two different VB-medias is no
greater than 1 in 2^96" seems to ignore the size of the set that we
choose "any pair" from. Would t
earch
Original Message
Subject: RE: Next P1619/1619.1 Meeting
From: "Matt Ball" <[EMAIL PROTECTED]>
Date: Tue, May 02, 2006 11:11 am
To: "james hughes" <[EMAIL PROTECTED]>
Cc: "Fabio Maino" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>,
<[EM
On May 1, 2006, at 3:27 PM, Matt Ball wrote:
All,
I just looked on the SISWG webpage, and it looks like there is a
"Conference on Mass Storage Systems and Technologies" in Maryland
between May 15-18. Since Jim Hughes is on the committee, I suspect
he won't be available during that week.
On Mar 8, 2006, at 3:47 PM, Matt Ball wrote:
Propose that bullet 3 in section 4.1 be reworded to: 4.1=20
"Plaintext P
shall have a length from 1 to 2^36-32 bytes".
I removed the 'record' language from this statement.
(Again, if we're supported 'authenticate-only', we need to
support =20
On Mar 7, 2006, at 6:11 PM, Matt Ball wrote:
Propose that bullet 3 in section 3.1 be reworded to: 3.1 "Plaintext P
shall have a length from 1 to 2^24"
It might be better to not impose any limit, but rather let the
particular
application define a limit. 16 MB is a customary limit in SCSI ta
it be and how long will it last?
Thanks,
-Matt
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
james
hughes
Sent: Sunday, February 12, 2006 6:20 PM
To: SISWG
Cc: james hughes
Subject: Re: Next meeting
Gentlepeople:
From my unofficial count is 7 y
Later is better
Shai Halevi OK
Fabio Maino y
Dalit Naor y
Garry McCracken y
Laszio y
Eric Hibbardy
On Feb 3, 2006, at 2:52 PM, james hughes wrote:
Gentlepeople,
I would like to suggest that
ions should count
as physically (or remotely) attending a meeting.
Laszlo
Original Message
Subject: Re: voting procedures for the working group to send P1619 on
to IEEE balloting?
From: Fabio Maino <[EMAIL PROTECTED]>
Date: Fri, February 03, 2006 9:32 pm
To: james hughes <
Gentlepeople,
I would like to suggest that the next meeting could be a phone
meeting on Feb 23rd?
Any yes, no, comments?
Jim
On Feb 3, 2006, at 1:54 PM, Landon Noll wrote:
Regarding the upcomming ballot for P1619 going on to IEEE balloting:
1) Where can I find a list of those companies / represenatives who
will be allowed to cast a vote?
Is there an official list somewhere?
This information is held by Fabio
Landon:
Thank you for your contributions. One of these suggestions I support
and the other I think you still have more homework on.
On Jan 18, 2006, at 1:26 PM, Landon Noll wrote:
Please be so kind as to add this to rationale:
The goal of the standard is to propose a mode of encryp
Hello: Me again
I have just received word that the link that I passed was no good.
Please go to Feb 14 from this page.
https://cm.rsaconference.com/US06/catalog/eventguide/publicSchedule.jsp
Jim
On Jan 18, 2006, at 2:57 PM, james hughes wrote:
I have the honor of chairing a
I have the honor of chairing a vendor neutral discussion of Storage
Security at the coming RSA conference. It will be Tuesday, February
14, 11:45 AM – 1:00 PM.
For more information see
https://cm.rsaconference.com/US06/catalog/profile.do?
SESSION_ID=2328&form=searchform
I am tempted to gi
Shai:
I think the off length has been talk about, and 2ndary issues as
well. Send around the text for the sector length paragraph and lets
see if there is consensus.
Jim
On Jan 17, 2006, at 3:55 PM, David McGrew wrote:
Shai,
that's a good suggestion. When a standard has a "free paramet
Laszlo:Your arguments will not be heard (by me at least) if I can not get past the first line.On Jan 17, 2006, at 6:01 PM, [EMAIL PROTECTED] wrote:[magnetic (hard) disk drives] Not necessarily, other technologies can use it as well. Jim repeatedly confirmed that P1619 is for spinning magnetic hard
I have just taught myself a lesson not to schedule deadlines over
holidays. Workgroup participation is spotty, and I am just now
getting back into this and a lot seems to have transpired that I have
not been following...
On Jan 17, 2006, at 9:18 AM, Shai Halevi wrote:
* It seems that there
Media
\f1\b0 \
\f2 a. Name of Working Group (WG):
\f3 \uc0\u8194 \u8194 \u8194 \u8194 \u8194
\f4\b SISWG
\f1\b0 \
\f2 b. Name of Working Group Chair:
\f3 \uc0\u8194 \u8194 \u8194 \u8194 \u8194
\f4\b James Hughes
\f1\b0 \
\f2 c. Name of Sponsoring Society and Committee:
\f3 \uc0\u8194 \u8194
uts and also
protects k1 if K2 is ever discovered.
I'm personally leaning towards using HMAC, although I could be
easily persuaded to use AES.
Any other thoughts?
-Matt
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
james
hughes
Sent: Thursday
Yes, it was discussed. From my recollections it actually predated GCM.
The rational was in the text and was edited out at the last revision.
The rational is
1) CCM has a smaller hardware and software footprint for
implementations that do not need the performance GCM.
2) A side issue (that
We have some challenges.
The CCM spec does not allow long IVs.
Thinking out loud... If we do not want to use SHA-1, would it be
possible to K2 = E_k1(id) or K2 = E_id(k11) where k1 is the key
provided, id is a 16 byte is vendor unique (or standard name) and K2
is the actual media key. This
This is indeed a very important issue.
In the case of a T10 compliant application pushing a key down to an
arbitrary drive which the application knows nothing about the vendor
(that is using a proprietary nonce). We need to make sure that vendor
A and B have a 0 chance of a collision.
I w
Agreed. But my question outstanding.
On Jan 4, 2006, at 2:18 PM, [EMAIL PROTECTED] wrote:
Shai is perfectly right. Here is another back-of-an-envelope
calculation:
We consider magnetic disks. The smallest domain size physically
capable
of storing magnetic information is about 3nm, 10^-1
I want to understand the issue here. I understand the bounds issue
with CBC and ECB, and as such are not relevant to this discussion
other than for history. The remainder is regarding LRW mode only...
My first statement is that I am not at all opposed to a statement
that this should only be
On Dec 22, 2005, at 11:04 PM, [EMAIL PROTECTED] wrote:
the difference [between LRW and EME] is the level of granularity.
With 4KB LBA's the difference in granularity is 256 fold, not a
trivial
amount.
On this you and I agree. When the decision was made to shelve EME a
4k sector was not as
All: Here is a request for more information about LRW.
Christian: Every meeting we ask if there are patents that are
relevant. this is to prevent patent submarines from the standard's
group participants. So far, no one has brought one forward. We also
have documents that show when LRW was f
On Dec 22, 2005, at 7:32 PM, [EMAIL PROTECTED] wrote:
a "wrong key behavior" can be beyond the scope
The issue is rather: can the raw, encrypted data be read from the
drive?
Maybe, the standard could just say in the introduction that LRW is
weak
against traffic analysis,
We know that LRW
On Dec 22, 2005, at 7:32 PM, [EMAIL PROTECTED] wrote:
[...] so the P1619 standard would only deal with a fraction of the
issues of securing data at rest.
Any standard needs to deal with as much as can be readily agreed on
understanding that more can be added later.
This unlocking becomes hard when there are a lot of partitions with
different keys that the drive does not know about...
I would suggest that a "wrong key behavior" can be beyond the scope
of the work here.
JIm
On Dec 22, 2005, at 1:14 PM, [EMAIL PROTECTED] wrote:
If you make the data ina
On Dec 20, 2005, at 12:49 PM, Elliott, Robert (Server Storage) wrote:
Encrypting the CRC, on the other hand, preserves some value for
storage purposes. However, if you decrypt with the wrong key,
the CRC will be wrong. This would complicate reading data from
a disk if you don't know the key - y
[...]The drive needs to encrypt the 512 bytes
of user data, calculate the CRC of the encrypted data, and store
that value rather than the plaintext CRC.
If we recalculate the CRC of the ciphertext, the end-to-end nature of
the CRC (which is why it is there in the first place) is lost since
o
On Dec 16, 2005, at 12:18 PM, Michael Torla wrote:
Although I am aware of no attacks on AES-ECB today, one may be
identified in the future.
Other than the obvious dictionary attack...
I should think it would be desirable to make the LRW somewhat
stronger than the base cryptographic algorit
be to encrypt all 520 bytes. This is simple because there is no parsing of the data stream. Don james hughes <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] No Phone Info Available12/14/2005 05:18 PMTo SISWG <[EMAIL PROTECTED]> cc james hughes <[EMAIL PROTECTED]> S
The 520 byte mode is important because it contains a CRC and other
"stuff" to determine the authenticity of the data...
If we did a mode that encrypted the extra 8 bytes using the counters
in this 8 as part of the tweak, and somehow manipulated the CRC so
that tamper anywhere in the packet
Gentlepeople:
The workshop in being held "as I type". there are about 50
participants (there were 8 walkins). Break even was 30, this was, in
my opinion, a great success. The papers area available at
http://ieeeia.org/sisw/2005/index.htm
I want to thank you for all your help!
jim
On Dec 8, 2005, at 3:02 PM, Shai Halevi wrote:
Garry McCracken wrote:
>All, attached are some comments and thoughts on IEEE 1619.1 for
discussion
> at the meeting Monday.
Some comments on the comments below.
> [...] the standard should allow the encryption to be performed at
the
> backup
On Dec 9, 2005, at 7:32 PM, [EMAIL PROTECTED] wrote:
A few questions:
The stated goal of the key backup procedure is to ensure that when
data
is encrypted using LRW-AES by one device compliant with the standard,
it can be decrypted by another device compliant with the standard,
using the exp
On Dec 8, 2005, at 8:05 PM, Elliott, Robert (Server Storage) wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Shai Halevi
Sent: Thursday, December 08, 2005 2:02 PM
To: SISWG
Subject: Re: an updated draft for p1619.1
Garry McCracken wrote:
All, a
The rest of the lurkers on this subject need to pipe up. This is one
of the first to contemplate a hardware implementation of LRW, so we
should listen.
On Dec 9, 2005, at 1:38 PM, Colin Sinclair wrote:
Recommendation: Section 5 should be carefully rewritten, removing
all references to T a
On Dec 3, 2005, at 8:04 AM, Shai Halevi wrote:
[...] The only good reason I can
think of to include this information is to facilitate a
'raw-write' and 'raw-read' operation. If this is the purpose, we
should state that in the standard. (Do we want this standard to
support interoperability at t
On Nov 29, 2005, at 6:54 PM, Shai Halevi wrote:
- Why does the Key ID need to be part of the AAD?
There is no crypto reason for that (but also no crypto reason not to
do it). I don't remember what was the reason that we decided to do
that. I think that some people were suggesting that perhaps s
At this time, I would suggest that we have morning for P1619 (aka
disk) and the afternoon for P1619.1 (aka tape). I would suggest that
there will be other agenda items but they will fit into these broad
categories.
Thanks
jim
On Nov 28, 2005, at 3:51 PM, Garry McCracken wrote:
Jim, I a
All:
I have some comments on the current draft.
Thanks
jim
On Nov 22, 2005, at 2:10 PM, Chris Kogelnik wrote:
Jim,
Some comments on the spec.
In section 4.1.1, "Multiplication Algorithm 1", there are a few
inconsistencies:
1. 'rightshift' should be 'leftshift'. The vectors shown in 4
On Oct 18, 2005, at 7:03 PM, Fabio Maino wrote:
> I would suggest the date for the face to face would be December 12,
> San Francisco (or the bay area).
Cisco can host the face to face meeting either in San Fran or San
Jose,
if needed.
OK. Great!
Thanks!
JIm
it's your call.
Please use these for the next draft you are generating.
Regards, Dalit.
"Elliott, Robert
(Server Storage)"
<[EMAIL PROTECTED]> To
Sent by: &qu
All:
We will re-schedule after we get the next round of drafts out. I will
be contacting the editors.
Thanks
jim
On Aug 10, 2005, at 9:32 PM, james hughes wrote:Start 10am Eastern, 7am Pacific Number (877) 216-6277 Code Agenda: Designate secretaryJim hughes Patent Slideset http://standards.ieee.org/board/pat/pat-slideset.pptAdvice and show Approve the Agendatake
On Sep 1, 2005, at 8:50 AM, james hughes wrote:Start Sept 1, 2005 10am Eastern, 7am Pacific Number (877) 216-6277 Code Agenda: Designate secretaryJim Patent Slideset http://standards.ieee.org/board/pat/pat-slideset.pptDiscussed Approve the AgendaNo
Start Sept 1, 2005 10am Eastern, 7am Pacific Number (877) 216-6277 Code Agenda: Designate secretary Patent Slideset http://standards.ieee.org/board/pat/pat-slideset.ppt Approve the Agenda Take membership Review action items. Review P1619 documen
The meeting will start at 10am eastern. I will email an agenda. The
goal of this meeting is to work on Serg's draft.
The dial in number will be 877-216-6277 and the id .
Thanks
jim
Is there something in the sample code for the test vectors that can shed some light on this?ThanksjimOn Aug 18, 2005, at 7:25 AM, Ken Buchanan wrote: LRW-AES does have some bit representations (with odd notation), and they correspond to 'big-endian', in contrast to the 'little-endian' representati
All:
If you want to be considered an "individual participating on standard
project" please fill in the attached .xls spreadsheet and send it to
me. I will consolidate it and send it in. Also please note in your
email if you want one or both (1619 and/or 1619.1). If you were to
send in one
The call in line was unable to accommodate the amount. The same
number as before (877) 216-6277 and the id is now #
Hi All:
I have been having troubles getting a bridge line together. My
usual service is "out of lines" to reserve. My apologies in
advance, if there are problems. I have
When you get in you need to press #ThanksjimOn Aug 10, 2005, at 9:32 PM, james hughes wrote:Hi All:I have been having troubles getting a bridge line together. My usual service is "out of lines" to reserve. My apologies in advance, if there are problems. I have never used this service
The timing could not be better.
We now have an approved tape project.
Thanks!
jim
Begin forwarded message:
From: "Jodi Haasz" <[EMAIL PROTECTED]>
Date: August 11, 2005 8:20:48 AM EDT
To: <[EMAIL PROTECTED]>
Cc: "Hughes, James P" <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]>
Subject: Approval
g 10, 2005, at 10:02 AM, james hughes wrote:Yes there is. It will be out shortly along with a preliminary (very simple) agenda. ThanksjimOn Aug 10, 2005, at 9:17 AM, Shai Halevi wrote:Are we still on for this meeting tomorrow? Is there a telephone number to call? -- Shai > Date: Tue, 05 Jul
I agree with Shai.
The argument that the market does not need this lacks a foresight.
GCM (or CCM for that matter) without a tag is pure counter mode
which, from a malleability standpoint, is -far- worse than CBC. I can
make any change to the ciphertext I want if I know the plaintext.
Whi
Yes there is. It will be out shortly along with a preliminary (very simple) agenda. ThanksjimOn Aug 10, 2005, at 9:17 AM, Shai Halevi wrote: Are we still on for this meeting tomorrow? Is there a telephone number to call? -- Shai > Date: Tue, 05 Jul 2005 12:38:52 -0400 > From: james
Agenda: Designate secretaryJim Hughes will act as secretary.Attendees:Serge PlotkinEric HibbardRob ElliottShai HaleviDalit NaorKen BuchananRichard MoeloerJames HughesDoug Whiting Approve minutes from last meetingJim moves Ken seconds approve minuets as amended by shai (on email) Action Fabi
The meeting call in information is:
Tele: +1 303 661 5100
ID:
Start
10am Eastern,
7am Pacific
Agenda:
Designate secretary
Approve minutes from last meeting
Patent Slideset
http://standards.ieee.org/board/pat/pat-slideset.ppt
Agenda
(Agenda items to b
On Jun 19, 2005, at 3:41 PM, Ken Buchanan wrote:
This clarifies the confusion a bit. My interpretation was a little
bit different, so I hope one of the T10 guys will weigh in and set
this straight.
Some of my thinking:
- A CRC of the plaintext data on disk represents information
leakage
I am confused by this. I thought that the idea of using the protection field was different. We should use the values that are in the protection field as input to the tweak, thus scrambling the data if the metadata is not correct, and then using the small CRC that is in the protection field to actua
All:
I am pleased to announce that Fabio Manio has agreed to assume
Clement Kent's position as secretary of P1619. He has responsibility
for the minutes and the membership list.
Thanks Fabio...
jim
Fabio Maino
Serge Plotkin
Doug Whiting
Eric Hibbard
Rob Elliott
John Buckingham
Shai Halevi
Dalit Naor
Ken Buchanan
Larry Hofer
Richard Moeloer
James Hughes
Please let me know if I missed anyone.
Thanks
jim
Here are 2 emails from Angela to the group.
Thanks
jim
Begin forwarded message:
From: <[EMAIL PROTECTED]>
Date: June 10, 2005 11:50:32 AM EDT
To: "Hughes, James P" <[EMAIL PROTECTED]>
Subject: IEEE process for amendment, corrigenda and revision.
Hello James:
Below please find more info o
This bounced. Please read the message from Eric. ThanksjimOn Jun 10, 2005, at 12:22 PM, IEEE LISTSERV Server ((14.3)) wrote From: Eric Hibbard <[EMAIL PROTECTED]> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> Subject: Structure of P1619 Standards Date: Fri, 10 Jun 2005 09:22:12 -0700 For the record
each sub document. These would be P1619.1, P1619.2, etc. Opening the new PAR is a 3 month hit. This will obviously be the primary part of the agenda for tomorrow. We also still have to create the voting pool. Talk tomorrow! Thanks!jimOn Jun 8, 2005, at 12:33 AM, james hughes wrote:The ca
The call in information is:Number:303.661.5100 6/10/2005 10am Eastern, 9am Central, 8am Mountain, 7am Pacific, meeting-id:This is expected to run for 2 hoursThere is a second call in number. This is:1pm Easter, 12pm Central, 11am mountain, 10am pacific. meeting-id 1112Agenda Revi
No meeting in Minneapolis because I will not be there to organize it.
If there are some people there that want to meet in a room, I will
call in.
Thanks
jim
On Jun 6, 2005, at 1:05 PM, Fabio Maino wrote:
No meeting in person in Minneapolis then?
I'm OK with extending (authenticating) the tweak to include the values of the the 2-byte Application Tag and 4-byte Reference Tag values. This makes sense to support the extended sector size. Cool ThanksjimOn Jun 1, 2005, at 9:07 AM, Elliott, Robert ((Server Storage)) wrote: (reviving an old thre
Yes, this is still on and I will post it. In looking at the minutes we didn't assign the action items. Can someone please remind me who was going to do the local arrangements (and accept my apologies in advance if it was me?)THanks!jimOn May 21, 2005, at 7:29 AM, Elliott, Robert ((Server Storage))
I would be interested if anyone on this list knows anyone involved in
this standard?
Thanks
jim
On Apr 26, 2005, at 4:04 PM, Curtis Anderson wrote:
All,
Just in case you didn't see this yet:
http://www.eet.com/news/latest/showArticle.jhtml?articleID=161600259
The four companies have also
Is there one of the local people coming/driving that would be willing
to bring a data projector?
Thanks
jim
All:
Please email the list with pointers to the most recent documents.
Thanks
jim
allot
LRW, EME,
- Other modes
- Tape encryption
Please respond if you are going to talk on these issues and/or for
additional items to discuss.
Thanks
jim
On Mar 15, 2005, at 8:06 AM, james hughes wrote:
For those thinking about traveling to the next meeting, there is a
room
block for the
will be required upon arrival in order to
receive the government per diem rate. Attendees will reference IEEE
Computer Society MSST when making reservations. The reservation
cut-off date will be Monday, 21 March 2005 at 5:00 p.m. Pacific time.
On Mar 9, 2005, at 2:09 PM, james hughes wrote:
I
I propose the next meeting April 14th and 15th in Monterey CA. Since we
have a fair number new people, I propose a general session (what and
why we are here) the starting at 3:30pm Thursday April 14th and the
general meeting all day Friday April 15th.
This is at the same place as the Mass Storage c
With the holidays over, we have to get back at this.
Serge: Any news on hosting this?
Thanks
jim
Begin forwarded message:
From: Eric Hibbard <[EMAIL PROTECTED]>
To: "'[EMAIL PROTECTED]'"
Subject: Next P1619 Meeting
Date: Wed, 12 Jan 2005 17:51:28 -0800
Have we set the specifics on the next P1619 me
You can look at the claims yourself, the application is online.
http://appft1.uspto.gov/netacgi/nph-Parser?
Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-
adv.html&r=1&p=1&f=G&l=50&d=PG01&S1=rogaway.IN.&OS=IN/rogaway&RS=IN/
rogaway
or shorter,
http://tinyurl.com/3u3tx
I believe the claim is
f data repeat, so there is no huge
difference in security.
Laszlo
> Original Message
> Subject: Re: [dm-crypt] LRW has more data modification leakage than
> CBC?
> From: "James Hughes" <[EMAIL PROTECTED]>
> Date: Sat, December 25, 2004 12:30 pm
This is correct. Using this "data modification leak" terminology, LRW
has more, CBC less and EME none.
EME and ABL encrypts the entire sector as a single permutation. Any bit
changed anywhere, the entire sector is changed. CBC leaks the point at
which the change starts.
So, instead of going to CBC
Great work. Does this mean that we will get this in Linux distro?!
Do we have test vectors for EME yet?
Thanks!
jim
On Dec 5, 2004, at 11:03 AM, Yaron Klein wrote:
OK, Now everything is in the right direction and correct.
Thanks Cyril,
Yaron
-Original Message-
From: Cyril Guyot [mailto:[EM
Fruhwirth: The committee has not specifically taken up the issue of
free software using the patent since it is a moot point. The right
person is Phil, since he is the inventor. I have CC'd him above.
Phil: to get you up to speed, Fruhwirth is interested in putting your
mode into Linux as a standard
On Nov 2, 2004, at 7:28 PM, Fruhwirth Clemens wrote:
On Tue, 2004-11-02 at 16:53 -0500, [EMAIL PROTECTED] wrote:
> Is there any plausible reason why any key length
> longer than 128 bits should seriously be considered?
Actually, AES key setup takes longer for shorter keys. I can remember
128 bit j
1 - 100 of 102 matches
Mail list logo
