Cryptography-Digest Digest #462, Volume #13 Fri, 12 Jan 01 17:13:00 EST
Contents:
Re: Linear analysis (Benjamin Goldberg)
Re: rc4 in javascript bug (Benjamin Goldberg)
Re: $$$$$ Compiler positions $$$$$ (Tom St Denis)
Re: Differential Analysis (Tom St Denis)
CHES 2001 --- 2nd CFP (Christof Paar)
Re: Different DES ("David C. Barber")
Re: Different DES (Jim Gillogly)
Re: NSA and Linux Security (John Myre)
Re: 16bit collision resistance hash function? ("[Basic]")
----------------------------------------------------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Linear analysis
Date: Fri, 12 Jan 2001 20:12:11 GMT
Tom St Denis wrote:
>
> In article <[EMAIL PROTECTED]>,
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> > I thought it was (2/p)^r, not 1/(p^2)? How do I go from knowing
> > about the Walsh Transform of a function, to knowing how many rounds
> > are needed to make the cipher secure against linear attacks?
>
> Oops... it is infact P = p^(-2) (P = required plaintexts). 2/p is
> from differential analysis.
p^-2 is (1/p)^2. So for differential analysis, P = (2/p)^r, and for
linear analysis, P = (1/p)^2r, yes? For differential analysis, p is the
max differential probability, and for linear analysis, p is ___? The
max (or abs max) value of the Walsh Transform? Or something like that?
[snip]
> > Thus, using r > 16/7 should be sufficient to protect against
> > differential attacks.
>
> This is not true. A Feistel with only two rounds CANNOT be secure.
> You need at least three rounds for the Luby-Rackoff condition of
> security. I would use at least three or four rounds.
16/7 is about 2.3. For r to be greater than (NOT greater than or equal
to), it must be 3 or more. Remember that the number of rounds is an
integer. Also, even if I'd calculated that r need only be 2 to be
secure against differential attacks, this would be true in spite of the
Luby-Rackoff condition... it would not be secure, but you still wouldn't
be able to do a differential attack against it, either.
> > But what do I need r to be to protect a 16 bit fiestel from LINEAR
> > attacks? That's what I need to know.
>
> Well if you are using the AES sbox this is (16/256)^-2 or
> 65536/256=256. So after two rounds (256)(256) = 65536 you are set.
Where does the 16/256 come from? And *here* is where "A Feistel with
only two rounds CANNOT be secure," comes into play...
Anyway, finding the number of rounds needed for security against linear
attacks algebraically is as follows:
(1/p)^2r > 65536
(256/16)^r2 > 65536
16^2r > 65536
log2(16^2r) > log2(65536)
2r log2(16) > log2(65536)
2r * 4 > 16
r > 2
Again, note the >, not >=.
> However, you can often bypass at least one round (It provable that in
> a Feistel with a Bijective round function that in three rounds you
> must attack at least two rounds, I did it in my TC5 paper :-)).
I assume that you mean that in a Feistel with N rounds, you need only
attack N-1 rounds -- so to attack a 3 round fistula, you must attack 2
rounds of it.
Also, for linear_test() in sboxgen, you have something like:
for (x = 1; x < n; x++)
for (y = 0; y < n2; y++) {
t = WalshTransform(f, n, x, y);
if (t > high)
return 0;
else if (t < low)
return 0;
}
Ignoring that it should probably be for(y=1... not for(y=0... I'm
curios... why do you have a test for low? Wouldn't it be just as good
to say if( iabs(t) > high ) ?
Up where you said (1/p)^2r plaintexts are needed for linear analysis,
might I possibly assume that p here is the max abs(Walsh Transform
value)?
(Well, actually you said p^-2 plaintexts, but it's the same thing).
> > > Keep in mind that the algebraic degree (sans the affine transform)
> > > is low and can be manipulated with interpolation attacks (Knudsen
> > > has a paper on the subject).
> >
> > Well, I'm considering using the AES sbox *with* the transform... or
> > the TC5 sbox. Is the WalshTransform the same as the algebraic
> > degree?
>
> No. Unfortunately I am not well versed on Algebraic degree. However,
> you should read Knudsens paper anyways.
>
> > And how does it (either the WT, or the algebraic degree) help me
> > perform (or help me prevent) a linear attack on the cipher?
>
> Dunno.
Hrm... I guess that finding the WT is like one of those primality tests
which can tell you that a number isn't prime, but not tell you any
factors of it. Too high a WT is bad, but with no indication of what the
attack is.
--
Power interrupts. Uninterruptable power interrupts absolutely.
[Stolen from Vincent Seifert's web page]
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: rc4 in javascript bug
Date: Fri, 12 Jan 2001 20:22:45 GMT
This is a multi-part message in MIME format.
==============CAAD8C328A42A9BDCD1CE8CE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
[EMAIL PROTECTED] wrote:
>
> I need to escape and unescape in that order for html code only because
> having the following characters : < > & could be interpreted as a tag
> fragment or the start of an accentuated character. But now, I think
> that I need to do this :
>
> - escape(encrypt(escape(plain html)))
> - unescape(decrypt(unescape(encrypted html)))
>
> ... but I'd rather try writing a java applet if it's really slow. Is
> avoiding the evals in the swap function still making it a viable
> option?
Avoiding evals in the swap helps some, but how much, I don't know.
You seem to have slightly confused what needs to be escaped at what
time. Given the plain html, you do NOT need to escape < > & before
encrypting. The encrypter can handle these perfectly fine. However,
AFTER encrypting, you have many characters which are not valid ascii,
let alone html. Funky wierd characters, nonprinting characters, things
with the top bit set. When sending this type of thing over the 'net,
these characters can (and often are) munged, mangled, and otherwise
f***ed up. THESE characters have to be escaped, and I don't mean in
terms of < > or &. What you need is something like the following:
encrypted text = uuencode( encrypt( plain text ) )
plain text = decrypt( uudecode( encrypted text ) )
uuencode is fairly space efficient, although both base64 encoding and
hexidecimal encoding are easier to implement.
I'm attaching an html file which does rc4 email encryption.
--
Power interrupts. Uninterruptable power interrupts absolutely.
[Stolen from Vincent Seifert's web page]
==============CAAD8C328A42A9BDCD1CE8CE
Content-Type: text/html; charset=us-ascii; name="SelfDecrypt.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="SelfDecrypt.html"
Content-Base: "file:///C|/Ben/temp/SelfDecrypt.html"
<!-------------------- SelfDecrypt.html ----------------------------->
<!-- Copyright 1998-2000, v. 1.1 Leemon Baird http://Leemon.com -->
<!------------------------------------------------------------------->
<HTML>
<HEAD>
<TITLE>SelfDecrypt: Send Self-Decrypting, ARCFOUR-Encrypted Email with
JavaScript</TITLE>
<BODY link=#009000 alink=#00e000 vlink=#004000>
This page sends encrypted email that automatically decrypts itself when
the recipient types in the passphrase. This is automatic if the sender
uses Netscape and the recipient uses Netscape or Internet Explorerer as
a mail reader. The email is encrypted with ARCFOUR, which is generally
considered secure.
<SCRIPT language=Javascript><!--
function x(i,j) {u=d[i];d[i]=d[j];d[j]=u;}
hex=new Array('0','1','2','3','4','5','6','7','8','9',
'a','b','c','d','e','f');
d = new Array(256);
function encrypt_and_send() {
f = document.forms.f; q = document.forms.q;
if(f.passphrase.value!=f.passphrase2.value
|| f.passphrase.value=='') {
f.passphrase.value='';
f.passphrase2.value='';
return false;
}
g=f.p.value;
f.p.value = '******** Encrypting, please wait ... ********';
len=g.length;
if (!f.m.checked)
a=g;
else {
for (a='<pre>',k=0;k<len;k++) {
h=g.charAt(k);
a+=h=='>' ? '>' : h=='<' ? '<' : h=='&' ? '&' : h;
}
a+='</pre\>';
}
skip=256;
dt=new Date();
iv=dt.getTime();
w='<script> '+'IV="'+iv+'"; skip='+skip+'; a=\n"#';
y=iv+f.passphrase.value;
for(i=0;i<256;i++) d[i]=i;
for(i=j=0;i<256;i++) x(i,j=(j+d[i]+y.charCodeAt(i%y.length))&255);
for(i=j=s=0;s<skip;s++) x(i=(i+1)&255,j=(j+d[i])&255);
len=a.length;
for (s=0;s<len;s++) {
x(i=(i+1)&255,j=(j+d[i])&255);
b=d[(d[i]+d[j])&255] ^ a.charCodeAt(s);
if (s>1 && s%35==0)
w+='"+\n"#';
w+=hex[b>>4] + hex[b&15];
}
w+='";\n'
+'w="";\n'
+'function x(i,j){t=d[i];d[i]=d[j];d[j]=t;}\n'
+'y=IV+prompt("Please enter passphrase:","");\n'
+'d=new Array(256);\n'
+'for(i=0;i<256;i++)d[i]=i;\n'
+'for(i=j=0;i<256;i++)\n'
+' x(i,j=(j+d[i]+y.charCodeAt(i%y.length))&255);\n'
+'for(i=j=s=0;s<skip;s++)x(i=(i+1)&255,j=(j+d[i])&255);\n'
+'for(k=0,s=-1;;k+=2){\n'
+' if(!(s=(s+1)%35))k=a.indexOf("#",k)+1;\n'
+' if(isNaN(h=parseInt(a.substr(k,2),16)))break;\n'
+' x(i=(i+1)&255,j=(j+d[i])&255);\n'
+' w+=String.fromCharCode(d[(d[i]+d[j])&255]^h);\n'
+'}\n'
+'document.write(w);\n'
+'</script></html>\n';
cm='<html><!--\n\n\n'
+'This email was encrypted using SelfDecrypt v. 1.1 \n'
+'by Leemon Baird, http://Leemon.com\n'
+'To decrypt and read it, load it into Netscape or Internet'
+' Explorer. \nJavaScript must be enabled to read it.\n\n\n'
+'--'+'>';
if (f.t.value=='') {
z=open('','z','width=660,height=460,scrollbars=1,resizable=1');
z.document.write('<html><body bgcolor=green>'
+'<font color=lime><h2>This is what would have been '
+'emailed if an email address had been entered:</h2></font>'
+'<form name=f>'
+'<textArea name=t mode=nowrap rows=20 cols=75>'
+'</textArea></form></body></html>');
z.document.close();
z.document.f.t.value='Subject: '+f.s.value+'\n'
+'Content-type: multipart/form-data; '
+'boundary=--BoUnDaRy\n'
+'--BoUnDaRy\n'
+'Content-Disposition: form-data; name=\x22email\x22\n'
+'Content-Type: text/html; charset=us-ascii\n'
+'Content-Transfer-Encoding: 7bit\n\n'
+cm+'\n'+w+'--BoUnDaRy';
f.p.value = g;
return false;
}
q.action='mailto:'+f.t.value+'?Subject='+f.s.value;
q.body.name='email\x22\nContent-Type: text/html; charset=us-ascii\n'
+'Content-Transfer-Encoding: 7bit\n\n'
+cm+'\n\n\n\n\n\n\x22\n';
q.body.value=w;
f.p.value=g;
return true;
}
//--></SCRIPT>
<CENTER>
<TABLE bgColor=green border=0 cellspacing=0 cellpadding=0>
<TBODY>
<TR>
<TD align=right>
<FORM name=q action=mailto: encType=multipart/form-data
language=JAVASCRIPT method=post
onsubmit="return encrypt_and_send()"><BR>
<INPUT type=submit value="Email to:">
<INPUT name=body type=hidden>
</FORM>
<FORM name=f></TD>
<TD><INPUT name=t size=60></TD></TR>
<TR>
<TD align=right><font color=lime><b>Subject:</b></font></TD>
<TD><INPUT name=s size=60></TD></TR>
<TR>
<TD align=right><font color=lime><b>Passphrase:</b></font></TD>
<TD><INPUT name=passphrase size=60 type=password></TD></TR>
<TR>
<TD align=right><font color=lime><b>Passphrase:</b></font></TD>
<TD><INPUT name=passphrase2 size=60 type=password></TD></TR>
<TR>
<TD align=right><font color=lime><b>Message:</b></font></TD>
<TD><TEXTAREA cols=60 name=p rows=15
mode="nowrap"></TEXTAREA></TD></TR>
<TR>
<TD align=right><INPUT name=m type=checkbox CHECKED
defaultChecked="true"><font color=lime><b>No_HTML</b></font></TD>
<TD><font color=lime><b>The recipient normally will see exactly what
is typed in the Message box above.<br>If, instead, you would
rather type HTML code into the box, and have the recipient see
what it looks like after being interpreted, then uncheck this
box.</b></font><BR></TD></TR>
</FORM>
</TABLE></CENTER>
<br>
<br>
<table border=0 cellspacing=0 cellpadding=0 bgcolor=green>
<tr><Td width=200 align=center>
<font color=lime><b>Instructions</b></font></td></tr>
</table>
Enter the email address of the recipient, the subject for the email, the
secret passphrase (twice), and the message that is to be encrypted and
sent. Then click "email to". The recipient doesn't need a decryption
program. The email will automatically decrypt itself if the sender used
Netscape and the recipient used Netscape or Microsoft Internet Explorer
as a mail reader.<br><br>
If the sender doesn't have Netscape, click "email to" without
entering any email address, and the encrypted message will appear in a
new window. That message can be cut and pasted into any email program.
If the recipient doesn't use Netscape or MSIE for email, the recipient
should save it to a file named EMAIL.HTML, and load it into a browser to
read it.<br><br>
If the two passphrases don't match, then both are erased, and no email is sent.<br><br>
Netscape warns that the email will be unencrypted, but in this case it
is wrong. The outer wrapper will not be encrypted, but the contents
will be.<br><br>
Save this page to disk and edit it to see the actual code doing
the encryption and sending the email.<br><br><br>
<table border=0 cellspacing=0 cellpadding=0 bgcolor=green>
<tr><Td width=200 align=center><font color=lime><b>Security</b></font></td></tr>
</table>
The encryption is done locally and is never sent to the web server,
so the server cannot see the message, and cannot tell who is being sent
the email. Of course the server could modify this page to eavesdrop, but
if you know JavaScript and HTML, you can save this page to disk and read
through it to make sure that didn't happen. An email server could also
attack the message that is created, modifying it capture the recipient's
passphrase as it's entered. The message should at least be secure
against passive eavesdropping.
<br><br>
This encryption program uses ARCFOUR, implemented in JavaScript. The IV
is the current time in milliseconds (decimal digits in ASCII). The key
is the concatenation of IV + passphrase. The first 256 bytes of stream
are dropped. If you <A href="http://www.leemon.com/crypto/MakePass.html">create a good
passphrase</A>, it will be impossible to break this through brute force.
At this time, there is no publically-known way to break this faster than
brute force.<br><br>
For more information about ARCFOUR, see section 17.1 of
<CITE>Applied Cryptography, 2nd ed.</CITE>, by Bruce Schneier. He uses
the trademarked name for the algorithm, derivable from "ARCFOUR" by
dropping the "A" and converting "FOUR" to a digit.<br><br>
<B>NOTE:</B> This page contains only open-source crypto code, and the BXA was notified
of its existence in accord with <A
href="http://www.bxa.doc.gov/Encryption/pdfs/Crypto.pdf">this</A> EAR amendment (p. 2,
last column).
</BODY>
</HTML>
==============CAAD8C328A42A9BDCD1CE8CE==
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: alt.sources.crypto,ott.jobs
Subject: Re: $$$$$ Compiler positions $$$$$
Date: Fri, 12 Jan 2001 20:24:38 GMT
In article <faJ76.2524$[EMAIL PROTECTED]>,
"Kris DeGiacomo" <[EMAIL PROTECTED]> wrote:
> Company Profile Description
>
> Our client is a leading edge start-up located in Ottawa's Silicon Valley
> North. The company develops and sells security products and technologies
> that enable E-Commerce. Their mission is to become a leader in the market
> for software protection technology and applications.
That is such meaningless gibbly-gook
"products and technolgoies that enable E-Commerce"... Hmm that includes
copper, steel, aluminum, plastic, rubber, carpets, wd-40, 3-in-1 oil, pepsi
cola, piii processors, 133Mhz SDRAM, gnu C compilers, Windows NT, monitors,
kleenex, cars, mass transportation, paper, chewing gum and possibly even a
mascot. That's only a brief list of things involved.
>
> This company has developed a radical new security technology that converts
> software into a tamper resistant form. It is believed to be the first
> software technology to provide a high degree of protection against both
> tampering and reverse engineering. The company is focused on commercializing
> this technology through partnerships with leading OEMs and by developing
> applications of the technology.
This company is Cloakware (I work for them).
> This dynamic organization is growing rapidly with unbounded opportunity for
> career growth and continued learning. Competitive salaries and benefits are
> standard along with stock options.
I work for them and I don't get stock options... :-)
> Responsibilities
Oooh bad word!
Hehehe..
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Differential Analysis
Date: Fri, 12 Jan 2001 20:21:21 GMT
In article <[EMAIL PROTECTED]>,
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> [snip]
> > > Anyway... I now have changed to something resembling your code, and
> > > it strangely tells me that *all* differences (even 0->0) have
> > > probability 1/256 -- which is clearly wrong.
> >
> > Yup should be wrong :-)
> >
> > > Here's my new code:
> > > void probs(/*char* file,*/ unsigned char *sbox) {
> > > int x, y;
> > > FILE * f = /*fopen(file,"w")*/ stdout;
> > > unsigned int table[256][256] = {0};
> > > for( x = 0; x < 256; ++x )
> > > for( y = 0; y < 256; ++y )
> > > ++table[x^y][sbox[x]^sbox[x^y]];
> > > printf("Differences calculated\n");
> > > for( x = 0; x < 256; ++x )
> > > for( y = 0; y < 256; ++y ) {
> > > if( table[x][y] <= 1 ) continue;
> > > fprintf(f,"%02x->%02x ",x,y);
> > > fprintf(f,"(%d/256)\n",table[x][y]);
> > > }
> > > /*fclose(f);*/
> > > }
> >
> > I would memset the table first. I dunno if = { 0 } will set all the
> > elements. Also this function should work...
> >
> > > Any idea what I'm doing wrong, here?
> >
> > Is the SBOX valid? Look at my sboxgen code if you need pointers.
>
> Of course the sbox is valid. In fact, you even said that my AES sbox
> generating code was correct. Besides, even with an invalid sbox, it
> should be quite impossible to get all differences have probability
> 1/256. In fact, I think that all differences must be (even number)/256.
>
> So what's wrong with my differential probability calculating code?
The numbers must be even since it's a "xor-pair" table :-)
Um send me your entire file to [EMAIL PROTECTED] and I will check it out.
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Christof Paar <[EMAIL PROTECTED]>
Crossposted-To: comp.arch.fpga,comp.arch.arithmetic
Subject: CHES 2001 --- 2nd CFP
Date: Fri, 12 Jan 2001 15:58:42 -0500
We apologize for multiple mailings. -Christof Paar
===================================================================
WORKSHOP ON CRYPTOGRAPHIC HARDWARE AND EMBEDDED SYSTEMS
(CHES 2001)
www.chesworkshop.org
Paris - France
May 13 - 16, 2001
Second Call for Papers
General Information
The focus of this workshop is on all aspects of cryptographic
hardware and embedded system design. The workshop will be a forum of
new results from the research community as well as from the industry.
Of special interest are contributions that describe new methods for
efficient hardware implementations and high-speed software for
embedded systems, e.g., smart cards, microprocessors, DSPs, etc. We
hope that the workshop will help to fill the gap between the
cryptography research community and the application areas of
cryptography. Consequently, we encourage submission from academia,
industry, and other organizations. All submitted papers will be
reviewed.
This will be the third CHES workshop. The first workshop, CHES '99,
was held at WPI in August of 1999 and was very well received by
academia and industry. There were 170 participants, more than half of
which were from outside the United States. The second workshop, CHES
2000, was also held at WPI in August of 2000 and had an attendance of
180.
The third workshop, CHES 2001, will be held in Paris in May of 2001.
The topics of interest include but are not limited to:
* Computer architectures for public-key cryptosystems
* Computer architectures for secret-key cryptosystems
* Reconfigurable computing and applications in cryptography
* Cryptographic processors and co-processors
* Modular and Galois field arithmetic architectures
* Tamper resistance on the chip and board level
* Smart card attacks and architectures
* Efficient algorithms for embedded processors
* Special-purpose hardware for cryptanalysis
* Fast network encryption
* True and pseudo random number generators
* Cryptography in wireless applications
Instructions for Authors
Authors are invited to submit original papers. The preferred
submission form is by electronic mail to [EMAIL PROTECTED]
Papers should be formatted in 12pt type and not exceed 12 pages (not
including the title page and the bibliography). The title page should
contain the author's name, address (including email address and an
indication of the corresponding author), an abstract, and a small
list of key words. Please submit the paper in Postscript or PDF. We
recommend that you generate the PS or PDF file using LaTeX, however,
MS Word is also acceptable. All submissions will be refereed.
Only original research contributions will be considered. Submissions
must not substantially duplicate work that any of the authors have
published elsewhere or have submitted in parallel to any other
conferences or workshops that have proceedings.
Important Dates
Submission Deadline: February 15th, 2001.
Acceptance Notification: March 31st, 2001.
Final Version due: April 21st, 2001.
Workshop: May 13th - 16th, 2001.
NOTE: The CHES dates May 13th - 16th are the Sunday - Wednesday
succeeding Eurocrypt 2001 which ends on Thursday, May 10th.
Mailing List
If you want to receive emails with subsequent Call for Papers and
registration information, please send a brief mail to:
[EMAIL PROTECTED]
Invited Speakers
Ross Anderson, University of Cambridge, U.K.
Protecting Embedded Systems - the Next Ten Years
Program Committee
Ross Anderson, University of Cambridge, England
Jean-Sebastien Coron, Gemplus, France
Kris Gaj, George Mason University, USA
Jim Goodman, Chrysalis-ITS, Canada
Anwar Hasan, University of Waterloo, Canada
Peter Kornerup, Odense University, Denmark
Bart Preneel, Katholieke Universiteit Leuven, Belgium
Jean-Jacques Quisquater, Universite Catholique de Louvain, Belgium
Christoph Ruland, University of Siegen, Germany
Erkay Savas, cv cryptovision, Germany
Joseph Silverman, Brown University and NTRU Cryptosystems, Inc., USA
Jacques Stern, Ecole Normale Superieure, France
Colin Walter, Computation Department - UMIST, U.K.
Michael Wiener, Entrust Technologies, Canada
Organizational Committee
All correspondence and/or questions should be directed to either of the
Organizational Committee Members:
Cetin Kaya Koc
(Publications Chair)
Dept. of Electrical & Computer Engineering
Oregon State University
Corvallis, Oregon 97331, USA
Phone: +1 541 737 4853
Fax: +1 541 737 8377
Email: [EMAIL PROTECTED]
David Naccache
(Program Chair and Local Organization)
Gemplus Card International
34 Rue Guynemer
92447 Issy les Moulineaux Cedex, FRANCE
Phone: +33 1 46 48 20 11
Fax: +33 1 46 48 20 04
Email: [EMAIL PROTECTED]
Christof Paar
(Publicity Chair)
Dept. of Electrical & Computer Engineering
Worcester Polytechnic Institute
Worcester, MA 01609, USA
Phone: +1 508 831 5061
Fax: +1 508 831 5491
Email: [EMAIL PROTECTED]
Workshop Proceedings
The post-proceedings will be published in Springer-Verlag's Lecture
Notes in Computer Science (LNCS) series. Notice that in order to be
included in the proceedings, the authors of an accepted paper must
guarantee to present their contribution at the workshop.
------------------------------
From: "David C. Barber" <[EMAIL PROTECTED]>
Subject: Re: Different DES
Date: Fri, 12 Jan 2001 14:37:36 -0700
"John Myre" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] wrote:
> <snip>
> > Where can I find an official description of DES?
> <snip>
>
>
> http://csrc.nist.gov/fips/fips46-3.pdf
>
> is about as official as you can get.
It might be as official as you can get, but my browser can't find anything
at that URL.
*David Barber*
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Different DES
Date: Fri, 12 Jan 2001 13:54:05 -0800
"David C. Barber" wrote:
>
> "John Myre" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > [EMAIL PROTECTED] wrote:
> > <snip>
> > > Where can I find an official description of DES?
> > <snip>
> >
> >
> > http://csrc.nist.gov/fips/fips46-3.pdf
> >
> > is about as official as you can get.
>
> It might be as official as you can get, but my browser can't find anything
> at that URL.
They appear to have reorganized the collection again. Try instead:
http://csrc.nist.gov/publications/fips/fips46-3.pdf
--
Jim Gillogly
Sterday, 21 Afteryule S.R. 2001, 21:51
12.19.7.15.17, 9 Caban 20 Kankin, Second Lord of Night
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: NSA and Linux Security
Date: Fri, 12 Jan 2001 15:00:38 -0700
David Wagner wrote:
<snip>
> However, if you do not have this level of blind faith in NSA, you
> might argue exactly the opposite: If there are credible allegations
> of abuse, they should be investigated very thoroughly, even if the
> evidence is not incontrovertible.
>
> And when one considers that the NSA are the only folks with the
> information one needs to judge whether there was abuse, it seems
> that placing the burden of the proof on the NSA may be the best choice.
<snip>
I'm not sure where you are going with this.
Question: how could the NSA "prove" that it did *not*
do something (wrong)? Moreover, how could it do so in
such a way as to keep (some) secrets?
(Presumably we accept the NSA charter; if we don't want
any secrets then we have to change that first.)
JM
------------------------------
From: "[Basic]" <[EMAIL PROTECTED]>
Subject: Re: 16bit collision resistance hash function?
Date: Fri, 12 Jan 2001 23:02:03 +0100
Hm, if I could fill such a bucket with 10.000.000 fixed hash values per
second, I would need about 60.000 years to complete the list.
>This isn't a cryptographically secure operation, but you did say collision
>resistance was the only criterion you needed to satisfy.
In fact I calculate the hash value over a 64bit long value and my problem is
that while transmitting the last few bits can get lost. As the 16bit hash
value is also transmitted the receiver should be able to reconstruct the
last few (up to ~25) bits by brute forcing and setting up a list of possible
solutions. This list should be as short as possible.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
