Well, it seems maybe you're mixing metaphors.  

If the goal is to replace RC4, then perhaps SOBER (without MAC) might make
some sense.
First of all, however, I'd like to be convinced that there's a real problem
with RC4, as opposed to how it is misused.  Saying that somebody has an
unpublished attack doesn't do much for me.  For better or worse, RC4 has
had lots of years to be attacked, so far with only a few very avoidable 
or fairly inconsequential dings in its armor (AFAIK), and replacing it with 
something new could end us up in far worse shape in a few years.  You may
know who has looked at it, but the crypto community in general probably
doesn't.
Have they published all their  analyses? Where?  This is the kind of stuff
that 
must be very carefully considered before making a change from "the devil we
know".
I guess basically I'd like some proof that RC4 needs deprecation. I'm not
aware
of any compelling motives for that, thought I certainly may be wrong.

If the goal is a combo encryption+MAC algorithm, then I stand by my
desire for quite a while for open study.  Saying that the possible need for
an RC4 replacement dictates acceptance of a new type of algorithm that does
something that RC4 doesn't even attempt to do seems like a bad argument.

So, which point are you trying to argue?  They're quite separate ones, from
my
perspective.


> -----Original Message-----
> From: Greg Rose [mailto:ggr@qualcomm.com]
> Sent: Monday, May 12, 2003 9:16 AM
> To: Doug Whiting
> Cc: 'Greg Rose'; cfrg@ietf.org; Alex Alten
> Subject: RE: [Cfrg] Authenticated encryption primitive -- SOBER-128
> 
> 
> I very much agree with the sentiments you express below. The only 
> difference between us is that I do know how much 
> cryptanalysis has been 
> applied, and who by. This makes me feel much more confident 
> in SOBER-128 
> than I have any right to expect others to feel.
> 
> Note that I, personally, think that Turing, SNOW 2.0 and 
> Helix are much 
> more "interesting" ciphers than SOBER-128. But I, like you, would not 
> recommend use of any of them yet.
> 
> But the reason we created SOBER-128 is not for cryptographic 
> interest. It's 
> because RC4 should be deprecated, but isn't. Perhaps we 
> should have named 
> it Chicxulub, which would address your concern about there 
> being too many 
> versions of SOBER :-).
> 
> Note: there have been 4 "kinds" of SOBER including this 
> latest. By "kinds" 
> I mean different word-sizes but same fundamental structure. 
> The first was 
> certainly broken (linear key loading). The second "S-class" 
> was marginal 
> against guess-and-determine attacks, and presumably has the same 
> distinguishing attacks as... The third "t-class" has no known attacks 
> except distinguishing attacks with insane (IMHO) amounts of known 
> plaintext, but a few rough edges. The fourth is SOBER-128. 
> There will be no 
> more.
> 
> regards,
> Greg.
> 
> At 03:50 AM 5/12/2003 -0700, Doug Whiting wrote:
> >I just want to express my concern about trying to make an RFC out of
> >anything like
> >this without considerable more time for analysis.  I agree 
> that various
> >flavors
> >of SOBER have seen some good amounts of cryptanalysis, 
> though I'm not sure
> >that
> >it has had enough yet (I'm simply not sure how many really 
> good folks have
> >spent
> >significant time on it).  One concern is that there have 
> simply been too
> >many SOBER
> >versions already, which urges some caution from my 
> perspective, although
> >there may
> >be very good reasons for the different versions. More 
> importantly, adding a
> >very significant new cryptographic "feature" such as a MAC 
> does not in any
> >way
> >constitute a "tweak" that should be assumed to inherit the security
> >properties of
> >the original algorithm(s).
> >
> >I say this as a co-author of Helix, and as someone who 
> belives, like you,
> >that such
> >combo algorithms are quite interesting. However, I believe 
> that this entire
> >concept
> >needs time for being carefully analyzed by the crypto 
> community before being
> >put into
> >serious use.  We simply are not there yet. The Helix folks 
> would consider it
> >quite
> >inappropriate to start standardizing at this time on any 
> such algorithm,
> >including Helix,
> >without quite a bit of time passing, perhaps a few years.  
> That's roughly
> >how much time
> >AES had, and it had (and continues to have) basically all the best
> >crpytanalysts looking
> >at it very seriously.  Of course, even just the passage of 
> time doesn't
> >guarantee that a
> >new algorithm (class of algorithms) has been propertly 
> vetted; the algorithm
> >must also
> >receive serious scrutiny from several well qualified folks. 
> That is, the
> >passage of such
> >time is a necessary but not sufficient condition.
> >
> >Don't take this as a criticism of SOBER-128 per se. I 
> believe that this
> >caution should
> >be applied to all algorithms of this class.
> >
> >Doug Whiting
> >
> > > -----Original Message-----
> > > From: Greg Rose [mailto:ggr@qualcomm.com]
> > > Sent: Sunday, May 11, 2003 3:07 PM
> > > To: Alex Alten
> > > Cc: Greg Rose; cfrg@ietf.org
> > > Subject: Re: [Cfrg] Authenticated encryption primitive -- 
> SOBER-128
> > >
> > >
> > > At 11:00 PM 5/10/2003 -0700, Alex Alten wrote:
> > > >Have you had any serious independent cryptanalysis done 
> on SOBER-128
> > > >that proves that it is well designed?  It's no good throwing
> > > it to the wolves
> > > >until you can defend it properly.
> > >
> > > Yes. If you read the details, SOBER-t32 has been analysed up
> > > the wazoo, and
> > > was secure at the 128-bit level; just not at the 256-bit
> > > level that we
> > > thought, which ruled it out of NESSIE. Most of this analysis
> > > was done on
> > > the "unstuttered" -t32, and applies directly to SOBER-128.
> > >
> > > regards,
> > > Greg.
> > >
> > > Greg Rose                                       INTERNET:
> > > ggr@qualcomm.com
> > > Qualcomm Australia          VOICE:  +61-2-9817 4188   FAX:
> > > +61-2-9817 5199
> > > Level 3, 230 Victoria Road,
> > > http://people.qualcomm.com/ggr/
> > > Gladesville NSW 2111    232B EC8F 44C6 C853 D68F  E107 E6BF
> > > CD2F 1081 A37C
> > >
> > > _______________________________________________
> > > Cfrg mailing list
> > > Cfrg@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/cfrg
> > >
> 
> 
> Greg Rose                                       INTERNET: 
> ggr@qualcomm.com
> Qualcomm Australia          VOICE:  +61-2-9817 4188   FAX: 
> +61-2-9817 5199
> Level 3, 230 Victoria Road,                
> http://people.qualcomm.com/ggr/
> Gladesville NSW 2111    232B EC8F 44C6 C853 D68F  E107 E6BF 
> CD2F 1081 A37C
> 
_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg