Folks,
Let us pay attention to some of these P1619 so-called "pink herrings"!
> I have not received any meaningful response to the issue of
> grandma storing her keys on an encrypted drive. The WG must
> have considered it the first time it came up ...
I have not spoken up until now because I
> > I would be happy to perform the detailed statistical analysis
> They were performed for AES, and we have a proof, that LRW
> does not significantly degrade the pseudorandomness of AES.
I do not know what you mean by "significantly degrades".
Also, please provide this proof. I'm asking not
Shai wrote:
> The plaintext is randomized, but this still leaves malleability
> issues as described (for example) in the annex of the standard.
Just so I am clear: by standard to you mean "the draft text for
the P1619 standards proposal" or do you mean some other adopted
standard? If you mean som
Monday 5/22 10am PDT or later (please)
Tuesday 5/23 noon PDT or later (please!)
works for me.
chongo (Landon Curt Noll) /\oo/\
> Is there anything else that we should change in the latest
> 1619.1 document?
> I'll go ahead and add these changes in, then add the new
> stuff, including the following:
>
> - Method for key derivation using SP800-90 DEC 2005 draft.
> - Requirements of entropy in IV if key derivation is not
Title: Message
Here is a link for the Draft Special Publication 800-90,
Recommendation for Random Number Generation Using Deterministic Random Bit
Generators:
http://csrc.nist.gov/publications/drafts/sp800-90_draft_dec2005.pdf
Watch
this link for updated draft that will incorporate th
> The week of Feb. 20 does not work for me. Could we push it to
> the following week? Larry H.
Pushing it to the next week would be better for me as well.
chongo () /\oo/\
Title: Message
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?
2)
What is needed to gain concensus and send P1619 on to IEEE b
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Serge Plotkin
> Sent: Tuesday, January 17, 2006 3:53 PM
> To: [EMAIL PROTECTED]
> Cc: SISWG; Shai Halevi
> Subject: RE: "the most important applications"
>
> As I have written several times before, the
> 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
> There are two ways that I see to solve the IV collision issue:
>
> 1. Allow longer IVs: The GCM spec allows IVs of any size, we can just
> do the same for 1619.1, and leave it to the application to
> decide how
> to set the IV and to what size. The application can then
> set the IV to
>
I'd like pause for a for the moment and say to those find
themselves saying:
"We have gone over this issue before! Do we have to go
over it again??"
I believe the answer must be YES! I believe the reason why it
keeps coming up by new members of the group is that the draft
lacks
> > > (I will spare you the back-of-an-envelope
> > > calculation of how long does it take to send 2^64 blocks over
> > > a 100 Gbit/sec link.)
> >
> > I think this argument is not very relevant. There was a time when
> > 2^32 blocks was considered huge and 2^48 blocks was and impossibly
> > l
> Although I have no problems with having the this discussion
> on the mailing list, I will object to having it in the
> standard itself. Standards are not an appropriate medium for
> this type of discussion. Counting "how many bits are leaked
> after 2^64 blocks" may be an amusing past-time, b
Title: Message
> Attached is another version the
p1619.1 draft, modified by Glen and
myself.
Thank
you Glen and Shai for the timely update.
>
Following the discussion in the last
meeting, we modified it to be very
permissive
>
in terms of what is written to
tape and in what
format.
Title: Message
I
believe that the draft needs a section called "Limitations and Compromises"
where issues such as what Matt Ball raised are addressed.
I believe that the draft is insufficient without
documenting your "At that point the
conclusion was that it does not buy us nearly anything
Title: Message
On
page 5 of D3, section 1.1 lists conditions as (a) thru (f). The following
paragraph refers to numbers instead of letters.
chongo
() /\oo/\
Title: documenting responses to common objections
> > There are other alternatives, too, which
> > are much better in this regard. I do not insist on reviving EME,
>
> I am excited that a 4k "EME like" algorithm (I seem to recall that
> there were 2 proposed in addition to EME that were
Title: RE: p1619 (disk): Security concerns of LRW and an alternative mode
> This document discusses ways to attack LRW through algebraic weaknesses in
> the Galois Multiplier. This attack becomes strong if Key2 (K2) looks
> similar to the plaintext (e.g. if K2 is an ASCII password). The r
19 matches
Mail list logo
