Cryptography-Digest Digest #825, Volume #12 Tue, 3 Oct 00 11:13:01 EDT
Contents:
Need help: considerations for IV and Keysetup ([EMAIL PROTECTED])
Re: NTRU question (actually truncated modular polynomial question) (Rasmus Faber
Larsen)
Looking Closely at Rijndael, the new AES (John Savard)
Re: Looking Closely at Rijndael, the new AES (John Savard)
Re: Idea for Twofish and Serpent Teams (SCOTT19U.ZIP_GUY)
Re: (fwd) A secure encrypted IRC network. (Pawel Krawczyk)
Re: Advanced Encryption Standard - winner is Rijndael (nemo outis)
Re: Looking Closely at Rijndael, the new AES (SCOTT19U.ZIP_GUY)
Re: Advanced Encryption Standard - winner is Rijndael ("Jill.B.G")
Re: Need help: considerations for IV and Keysetup (John Myre)
Re: Advanced Encryption Standard - winner is Rijndael (Johnny B)
Re: Advanced Encryption Standard - winner is Rijndael ("Jeff Moser")
Re: Choice of public exponent in RSA signatures (John Myre)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Need help: considerations for IV and Keysetup
Date: Tue, 03 Oct 2000 12:57:04 GMT
To avoid being a candiate for the Snake Oil Faq, I hope someone can
help me in my considerations with the following situation.
Outline:
I am currently writing a WinNT kernel driver to support encryption for
scsi tape drives(e.g. dat drives). For this purpose, I chose the
Twofish Cipher (might as well be Riyndael now that the standard has
been chosen) in CBC-Mode. The data which is to be encrypted/decrypted
is supplied in streams of bytes. Size of one stream is known and is
guaranteed to be a multiple of the Cipher`s Block Size (e.g. 0x4000h
bytes). Furthermore, for each stream, the physical block address is
supplied, the address which is accessed on the drive. A standard win32-
gui application receives a password from the user and communicates with
the kernel driver.
One major limitation in my implentation is that the size of the streams
should not be altered, neither - to remain compatible - is there
any "free" space where I could late store additional information
(IV, ...). In fact, there IS some free space, like in the header of
each tape cartridge, but that space might be used later in some future
version of the backup program been used with the result that encrypted
tapes are not compatible anymore.
Considerations:
1) Password Setup.
I want to use the highest strength of the chosen Cipher, i.e. 256bit.
How do I receive a 256bit key? I could generate 256bit pseudorandom
bits, save them in a key file, and ask the user to hide that file well
(e.g. on a floppy disk, steganography etc.).
Or, I could receive a password from the user, and generate a hash. The
problem is to receive a hash digest of size 256bit; I only know of
Haval (where copyright issues are not really clear, and its strengh to
me unknown) and a modified Ripemd (which strength is actually only that
of the 128bit version).
Yet I would prefer that all a user is required to do is to enter a
password to access his scsi tapes. Should I use Haval? Or could I use
something else. Like PKCS-5? I haven't looked at PKCS-5 yet, would love
to hear some comments.
2) Initialization Vector (IV).
The major difficulty here is that I have no space to store "random"
data that could be used as IV. All I have is the data stream that is
been encrypted/decrypted and the physical block number of that stream.
Is using the physical block number (4 bytes) sufficient for the IV (128
bit, 16 bytes)? I am afraid not. But even after a long time
consideration, I haven't found a satisifying solution.
Could I use the encrypted content of a predefined stream, lets say the
first stream that starts at block number 0, combine it with the block
number, and put both together into a hash function? Would I receive an
IV that unpredictably changes with each incremented block (based on the
nature of the hash function which produces unpredictable outcomes)?
Problem is that using this approach I could not derive an IV for the
first stream at block #0 itself. Using a predefined IV only for that
stream would solve this problem. Btw, the first stream only contains
the header information, that is medium name, date of creation, and
other information that does not reveal any information about the
content of the tape (no filestructure, file data etc). Any
recommendations?
Thinking about those things gives me a lot of headache and made me
almost want to stop my project.
Help is appreciated.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Rasmus Faber Larsen <[EMAIL PROTECTED]>
Subject: Re: NTRU question (actually truncated modular polynomial question)
Date: Tue, 3 Oct 2000 14:49:31 +0200
Reply-To: Rasmus Faber Larsen <[EMAIL PROTECTED]>
On Fri, 29 Sep 2000, Benjamin Goldberg wrote:
> Interesting, but it isn't psuedocode or C code, which is what I asked
> for.
Well, then you might be able to use this. It is not nearly as elegant or
clear as Contini's Magma-code, but at least it is in C.
You need some headers and a few additional functions located in some other
libraries, but if you have a little knowledge of mathematics, you ought to
be able to write them for yourself. If not feel free to email me, and I
will send you the rest.
With kind regards
Rasmus Faber Larsen.
--- polylib.c ---
/*
* Library to do various things to polynomials.
* Rasmus Faber Larsen ([EMAIL PROTECTED]) 2000
*/
#include <stdlib.h>
#include <polylib.h>
#include <newmath.h>
#include <math.h>
#define FALSE 0
#define TRUE 1
void poly_init(poly_ptr a){
a->deg=0;
a->coef=malloc((MAXDEG+1)*sizeof(long));
a->alloc=MAXDEG;
a->coef[0]=0;
}
void poly_clear(poly_ptr a){
free(a->coef);
a->alloc=-1;
}
void poly_realloc(poly_ptr a, int newsize){
/* Error checking */
if(newsize<a->deg)
printf("Error in polylib/realloc");
realloc(a->coef,(newsize+1)*sizeof(long));
a->alloc=newsize;
}
void poly_add(poly_ptr c, poly_srcptr a, poly_srcptr b,int p){
int i,t;
if(c->alloc<=max(a->deg,b->deg))
poly_realloc(c,max(a->deg,b->deg));
for(i=0; i<=min(a->deg,b->deg); i++)
c->coef[i]=mod(a->coef[i]+b->coef[i],p);
if(a->deg>b->deg)
for(i=b->deg+1; i<=a->deg; i++)
c->coef[i]=a->coef[i];
else
for(i=a->deg+1; i<=b->deg; i++)
c->coef[i]=b->coef[i];
t=0;
for(i=0;i<=max(a->deg,b->deg);i++)
if(c->coef[i]!=0)
t=i;
c->deg=t;
}
void poly_reduce(poly_ptr a, int p){
int i;
for(i=0;i<=a->deg;i++)
a->coef[i]=mod(a->coef[i],p);
while(a->coef[a->deg]==0)
a->deg--;
}
void poly_trunc(poly_ptr a, int n){
int i;
if(a->deg>=n){
for(i=n;i<=a->deg;i++)
a->coef[mod(i,n)]=a->coef[mod(i,n)]+a->coef[i];
for(i=1;i<=n-1;i++)
if(a->coef[i]!=0)
a->deg=i;
}
}
void poly_sub(poly_ptr c, poly_srcptr a, poly_srcptr b,int p){
int i,t;
if(c->alloc<=max(a->deg,b->deg))
poly_realloc(c,max(a->deg,b->deg));
for(i=0; i<=min(a->deg,b->deg); i++)
c->coef[i]=mod(a->coef[i]-b->coef[i],p);
if(a->deg>b->deg)
for(i=b->deg+1; i<=a->deg; i++)
c->coef[i]=a->coef[i];
else
for(i=a->deg+1; i<=b->deg; i++)
c->coef[i]=-b->coef[i];
t=0;
for(i=0;i<=max(a->deg,b->deg);i++)
if(c->coef[i]!=0)
t=i;
c->deg=t;
}
void poly_set_ui(poly_ptr b, poly_ui a){
int i;
if(b->alloc<=a[0])
poly_realloc(b,a[0]);
for(i=0; i<=a[0]; i++)
b->coef[i]=a[i+1];
b->deg=a[0];
}
void poly_set(poly_ptr b, poly_srcptr a){
int i;
if(b->alloc<=a->deg)
poly_realloc(b,a->deg);
for(i=0; i<=a->deg; i++)
b->coef[i]=a->coef[i];
b->deg=a->deg;
}
/*
* Returns 1 if a=b in (Z/pZ)[X] else returns 0
*/
int poly_eq(poly_srcptr a, poly_srcptr b,int p){
int i;
if(a->deg!=b->deg) return 0;
else
for(i=0; i<=a->deg; i++)
if(mod(a->coef[i]-b->coef[i],p)!=0) return 0;
return 1;
}
void poly_shiftleft(poly_ptr a, int n){
int i;
for(i=0; i<=a->deg-n; i++)
a->coef[i]=a->coef[i+n];
a->deg=a->deg-n;
}
void poly_shiftright(poly_ptr a,int n){
int i;
if(a->alloc<=a->deg+n)
poly_realloc(a,a->deg+n);
for(i=a->deg+n; i>=n; i--)
a->coef[i]=a->coef[i-n];
for(i=0; i<=n-1; i++)
a->coef[i]=0;
a->deg=a->deg+n;
}
/*
* Multiply a polynomium of degree <N-1 with an integer mod q;
*/
void poly_mult_ip(poly_ptr c, int n, poly_srcptr a, int q){
int i,t;
if(c->alloc<=a->deg)
poly_realloc(c,a->deg);
for(i=0;i<=a->deg;i++)
c->coef[i]=mod(n*a->coef[i],q);
t=0;
for(i=0;i<=a->deg;i++)
if(c->coef[i]!=0)
t=i;
c->deg=t;
}
/*
* Multiply two polynomiums in (Z/qZ)[X]/(X^N-1);
*/
void poly_mult_pp(poly_ptr H, poly_srcptr F, poly_srcptr G, int q, int N){
int k,i;
poly_t T;
if(H==F){ /* Check if F points to the same as H */
poly_init(T);
poly_set(T,F); /* Then copy F to a new variable */
if(H==G) /* Check if G also points to H */
poly_mult_pp(H,T,T,q,N);
else
poly_mult_pp(H,T,G,q,N);
poly_clear(T);
}
else
if(H==G){
poly_init(T);
poly_set(T,G);
poly_mult_pp(H,F,G,q,N);
}
else{
if(H->alloc<=F->deg+G->deg)
poly_realloc(H,F->deg+G->deg);
if(N==0){
for(k=0;k<=F->deg+G->deg;k++){
H->coef[k]=0;
for(i=0;i<=k;i++)
H->coef[k]=mod(H->coef[k]+F->coef[i]*G->coef[k-i],q);
}
H->deg=F->deg+G->deg;
while(H->coef[H->deg]==0)
H->deg--;
}
else{
for(k=0;k<=N-1;k++){
H->coef[k]=0;
for(i=0;i<=k;i++)
if ((F->deg>=i)&&(G->deg>=k-i))
H->coef[k]=mod(H->coef[k]+F->coef[i]*G->coef[k-i], q);
for(i=k;i<=N-1;i++)
if ((F->deg>=i)&&(G->deg>=N+k-i))
H->coef[k]=mod(H->coef[k]+F->coef[i]*G->coef[N+k-i], q);
}
H->deg=N-1;
while(H->coef[H->deg]==0)
H->deg--;
}
}
}
void poly_swap(poly_ptr a, poly_ptr b){
int cd,ca;
long *cc;
cd=a->deg;
ca=a->alloc;
cc=a->coef;
a->deg=b->deg;
a->alloc=b->alloc;
a->coef=b->coef;
b->deg=cd;
b->alloc=ca;
b->coef=cc;
/*int i;
poly_t c;
poly_init(c);
c->deg=a->deg;
for(i=0;i<=a->deg;i++)
c->coef[i]=a->coef[i];
a->deg=b->deg;
for(i=0;i<=b->deg;i++)
a->coef[i]=b->coef[i];
b->deg=c->deg;
for(i=0;i<=c->deg;i++)
b->coef[i]=c->coef[i];
poly_clear(c);*/
}
void poly_print(poly_ptr a){
int i;
printf("%d",a->coef[0]);
for(i=1;i<=a->deg;i++)
if ( a->coef[i] != 0 )
printf(" + %d x^%d", a->coef[i],i);
printf("\n");
}
/*
* Calculates inverse polynomials using the "Almost Inverse Algorithm"
* by Schroeppel, Orman, O'Malley and Spatscheck. See -do-, Fast key
* exchange with elliptic curve systems, Advances in Cryptology - CRYPTO 95
* LNCS 973 or NTRU Tech. Rep. #014.
*/
/*
* Finds the inverse polynomium of a in (Z/p^rZ)[X] / (X^N-1)
*/
void poly_inverse(poly_ptr b, poly_srcptr a, int p,int r, int N){
poly_ui tempui;
int k=0;
int i;
int u;
int q;
poly_t temppoly;
poly_t c,f,g;
poly_t one,two,minusone,zero;
poly_init(one);tempui[0]=0; tempui[1]=1;poly_set_ui(one,tempui);
poly_init(minusone);tempui[0]=0; tempui[1]=-1;poly_set_ui(minusone,tempui);
poly_init(zero);tempui[0]=0; tempui[1]=0;poly_set_ui(zero,tempui);
poly_init(two);poly_mult_ip(two,2,one,0);
poly_init(c);
poly_set(b,one);
poly_set(c,zero);
poly_init(f);poly_set(f,a);
poly_init(g);tempui[0]=N;tempui[1]=-1;for(i=2;i<=N;i++) tempui[i]=0; tempui[N+1]=1;
poly_set_ui(g,tempui);
if(r==1){
if(p==2){
while(poly_eq(f,one,p)==FALSE){
while(f->coef[0]==0){
poly_shiftleft(f,1);
poly_shiftright(c,1);
k++;
}
if (poly_eq(f,one,p)==FALSE){
if(f->deg<g->deg){
poly_swap(f,g);
poly_swap(b,c);
}
poly_add(f,f,g,p);
poly_add(b,b,c,p);
}
}
poly_shiftright(b,mod(N-k, N));
poly_trunc(b,N);
poly_reduce(b,p);
}
else if(p==3){
while(f->deg>0){
while(f->coef[0]==0){
poly_shiftleft(f,1);
poly_shiftright(c,1);
k++;
}
if (f->deg>0){
if(f->deg<g->deg){
poly_swap(f,g);
poly_swap(b,c);
}
if(f->coef[0]==g->coef[0]){
poly_sub(f,f,g,p);
poly_sub(b,b,c,p);
}
else{
poly_add(f,f,g,p);
poly_add(b,b,c,p);
}
}
}
if(f->coef[0]%3==2)
poly_mult_ip(b,2,b,p);
poly_shiftright(b,mod(N-k, N));
poly_trunc(b,N);
poly_reduce(b,p);
}
else{
while(f->deg!=0){
poly_init(temppoly);
while(f->coef[0]==0){
poly_shiftleft(f,1);
poly_shiftright(c,1);
k++;
}
if (f->deg!=0){
if(f->deg<g->deg){
poly_swap(f,g);
poly_swap(b,c);
}
u=f->coef[0]*inverse(g->coef[0],p);
poly_mult_ip(temppoly,u,g,p);
poly_sub(f,f,temppoly,p);
poly_mult_ip(temppoly,u,c,p);
poly_sub(b,b,temppoly,p);
}
poly_clear(temppoly);
}
poly_mult_ip(b,inverse(f->coef[0],p),b,p);
poly_shiftright(b,mod(N-k,N));
poly_trunc(b,N);
poly_reduce(b,p);
}
}
else{
poly_init(temppoly);
poly_inverse(b,a,p,1,N);
q=p;
while(q<pow(p,r)){
q=q*q;
poly_mult_pp(temppoly,a,b,q,N);
poly_sub(temppoly,two,temppoly,q);
poly_mult_pp(b,b,temppoly,q,N);
}
poly_clear(temppoly);
poly_trunc(b,N);
poly_reduce(b,pow(p,r));
}
poly_clear(one);
poly_clear(minusone);
poly_clear(zero);
poly_clear(two);
poly_clear(c);
poly_clear(f);
poly_clear(g);
}
********************************************************************
* Rasmus Faber Larsen * e-mail: [EMAIL PROTECTED] *
* Department of Mathematics * http://www.dfi.aau.dk/~faber *
* DK-8000 Aarhus C * office: F2.12 phone: (+45) 8942 3488 *
********************************************************************
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Looking Closely at Rijndael, the new AES
Date: Tue, 03 Oct 2000 13:10:07 GMT
I hadn't really made up my mind about Rijndael.
Given comments made about its security, I tended to be somewhat
dismayed that security didn't play a larger role in the selection
process, but since from the outset efficiency and speed were known to
play a large role in the selection, Rijndael seems to be the proper
winner.
I went and looked more closely at the design. It seems like one that
is indeed secure, since it puts the bits of the block through an
S-box, and uses a matrix to convolute the columns rather than a simple
Feistel XOR.
But I see one characteristic of the design that looks like a
cryptanalytic flaw - this is by analogy, which may be flawed, with
results on different block ciphers like DES, so, no, I don't have an
attack in hand. It is, of course, rather late to make comments of this
sort, and the considerations I am advancing here may well have been
examined, and rejected early in the procedure for good and sufficient
reason.
The number of rounds in Rijndael, if one does not count the last round
which omits the Mix Column step, can be either 9, 11, or 13. On
general principles, that number should instead be a multiple of four.
So for 128, 192, and 256 bit keys, I suppose the number of rounds
should be 12, 16, and 20, if the key schedule can somehow be changed
to accomodate this.
As it happens, because of attacks faster than brute force, increasing
the number of Rijndael rounds as the length of the key increases was
needed. But also in general, it makes more sense to leave the number
of rounds fixed with changes to the key size - but it is _vitally
necessary_ to increase the number of rounds if the block size
increases.
For 192-bit *blocks*, change 'multiple of four' to 'multiple of six',
and for 256-bit *blocks*, change 'multiple of four' to 'multiple of
eight'.
Since 13 regular rounds (14 rounds) was adequate for a 256-bit key,
perhaps then the number of rounds for Rijndael should be:
16 + 1 for a 128-bit block, regardless of key
24 + 1 for a 192-bit block, regardless of key
32 + 1 for a 256-bit block, regardless of key
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Looking Closely at Rijndael, the new AES
Date: Tue, 03 Oct 2000 13:44:04 GMT
On Tue, 03 Oct 2000 13:10:07 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>this is by analogy, which may be flawed, with
>results on different block ciphers like DES,
In the event this was too obscure a remark, I shall be explicit: Table
12.14, on page 289, AC 2nd edition.
I was going to wonder at the reason for the Shift Row step in the last
round, but upon reflection, that is presumably to make the deciphering
process more closely resemble the enciphering process (one still has
to invert the Shift Row direction, and make certain other changes).
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Idea for Twofish and Serpent Teams
Date: 3 Oct 2000 13:44:00 GMT
[EMAIL PROTECTED] (Zulfikar Ramzan) wrote in <[EMAIL PROTECTED]>:
>
>> Try saying that to Mr Schneier or Dr. Biham....
>>
>
>
>Actually, during the last AES conference, there was a closing remarks
>session in which one representative from each of the design teams
>participated. Someone asked the panel if they had to choose an
>algorithm for the AES other than their own, which would they choose.
>
>All of them said Rijndael (except for the Rijndael team, who said RC6
>because of its simple yet elegant design philosophy). Though, I should
>mention that Ross Anderson actually said "Rijnadel with 32 rounds."
>
If you look at this like the survivor series. It is quite possible
they all picked Rijndael since they expected it to lose. It would be
interesting to ask that same question today. It would provide a lot
of insite to how these people really think.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Pawel Krawczyk <[EMAIL PROTECTED]>
Subject: Re: (fwd) A secure encrypted IRC network.
Date: Tue, 3 Oct 2000 14:00:52 +0000 (UTC)
ge <[EMAIL PROTECTED]> wrote:
> Personally, I like the idea, and I believe it is done right.
> Also, I heard that some think it may have been better to use
> IPsec.
It could be redesigned from scratch with security in mind, as
it has been done in recently announced SILC (http://silc.pspt.fi/).
Really interesting protocol and seemingly with ambitions to become
a RFC standard.
--
Paweł Krawczyk <http://ceti.pl/~kravietz/>
------------------------------
Crossposted-To: alt.security.scramdisk
From: [EMAIL PROTECTED] (nemo outis)
Subject: Re: Advanced Encryption Standard - winner is Rijndael
Date: Tue, 03 Oct 2000 14:18:04 GMT
I'd like to briefly interrupt this quarrel to ask if there are any decent
sources of info in the public domain that discuss "endorsed algorithms" for
use at secrecy levels of confidential and up.
Regards,
In article <[EMAIL PROTECTED]>, Arturo
<[EMAIL PROTECTED]=NOSPAM> wrote:
>On 3 Oct 2000 05:08:00 GMT, [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
>wrote:
>
>>[EMAIL PROTECTED] (jungle) wrote in <[EMAIL PROTECTED]>:
>>
>
>>
>> Your own quote it is intended that AES ... protecting
>>sensitive government information. Sensitive is not even
>>considered classifed. It is below confidential info and
>>is to low to be considered classifed.
>>
> I think it´s just a mine-does-it-better syndrome. Either NSA is so
>paranoic it doesn´t trust AES, or it needs some excuse to keep a zillion+
>mathematicians/cryptographers on its payroll. But anyway, DES was intended to
>protect sensitive, non-classified information. And it fared well.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Looking Closely at Rijndael, the new AES
Date: 3 Oct 2000 14:16:22 GMT
[EMAIL PROTECTED] (John Savard) wrote in
<[EMAIL PROTECTED]>:
>I hadn't really made up my mind about Rijndael.
>
>Given comments made about its security, I tended to be somewhat
>dismayed that security didn't play a larger role in the selection
>process, but since from the outset efficiency and speed were known to
>play a large role in the selection, Rijndael seems to be the proper
>winner.
>
As much as I bad mouth the whole AES effort. I have tried to think
what I would do if I was to judge a cipher for the specifacations listed.
I don't think any small fast cipher can really be secure but I think the
security part has to be judged from two points of view. One does any one
have a reasonable break for the whole cipher. That being done, You treat
all the reamaing as at the same security level. Which of course is unture
but one should not speculate the order in which they will be broken since
they all will. If and when it gets easily broken you run another contest.
But of those that pass the so called security checks. You then go to
the one that is cheapest to impliment in the wide variety of uses that
cipher was meant for. After all only a small degree of security is needed.
One can't prove how secure each of these ciphers are to each other. You
only get a real measure if one is broken at which point you throw that
cipher out.
This was intended for commerical use. These ciphers should not be used
by any one who wants private truely secure encryption. For example the
governement will not allow it for anything but sensitive info. They will
not use it for secret info and you should not either. But hopefully it
is good enough so that no 14 year old hacker can easily break it with
his home computer in the next 20 years.
One should keep in mind the specification are such that if the NSA
has decent quantum computers. It is likely only a few blocks of data
would be needed such that in most cases only one solution could be backed
out. I don't think we will see 14 year olds with large quatum compters
in the next 20 years. But who knows.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: "Jill.B.G" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk
Subject: Re: Advanced Encryption Standard - winner is Rijndael
Date: Tue, 03 Oct 2000 15:37:03 +0100
"SCOTT19U.ZIP_GUY" wrote:
> ***Note sensitve not classifed that is a big difference***
What are, and what order of the various security levels?
Could you please post a list for me, perhaps with a brief explanation or
example of what would be protected by each security level.
Or point me to a resource that explains,
I would also be interested in which algorythms / security arrangements
are considered sufficient to protect the various levels.
Regards
Jill
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Need help: considerations for IV and Keysetup
Date: Tue, 03 Oct 2000 08:37:24 -0600
In terms of IV use, your requirement not to expand the data
at all matches the needs of disk encryptors. You might try
to find info on some of them. Look for SFS, Scramdisk, E4M,
Linux encrypted file systems, and more. In general the best
methods do extra work on the whole block (disk sector) before
the main encryption, which requires having the whole block
in hand. Can you do that?
In terms of key setup, I'd only comment that a 256-bit key
generated or protected by a password seems like a mismatch.
However, the more important viewpoint is to ask: what are
you trying to protect against? That is, why encrypt at
all? Who is your adversary? What can he do? These kinds
of questions can lead you to evaluating various schemes.
JM
------------------------------
Crossposted-To: alt.security.scramdisk
Subject: Re: Advanced Encryption Standard - winner is Rijndael
From: [EMAIL PROTECTED] (Johnny B)
Date: Tue, 03 Oct 2000 14:51:10 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote in
<[EMAIL PROTECTED]>:
> Fist of all the competions was not a world wide effort. The
>judging was done soley in the United States and other countries
>should take that fact into account before any real secrets are
>encrypted with it. Also the US does not consider it secure encough
>for classed information. That fact alone should make one wonder
>how secure of a method the NSA would allow the public to use.
>
______________________________
How do you know it wasn't 'worldwide'? Just saying so doesn't mean it
is so. True too, just because some dufus in the Dept. of Commerce
said it was a worldwide effort, doesn't mean it actually was either,
and though we don't trust the people who run anything much to do with
our government, we at least 'know' he's announced it publically, and
can prove who he is. You, we all don't know, and just pop in and say
something and expect everyone who reads it to believe it.
I don't mean this as a flame or nothing like that, I'm sorry if it
sounds that way, but I hope I got my point accross.
Goat
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
iQA/AwUBOdnznjdAp5vWTRQgEQIrIwCg1eO66XVZ+k/pFBJLKWZNvpxzU58An2No
VAmUdc6QurtuAuOvvbEYmbF/
=horI
=====END PGP SIGNATURE=====
------------------------------
From: "Jeff Moser" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk
Subject: Re: Advanced Encryption Standard - winner is Rijndael
Date: Tue, 3 Oct 2000 09:53:41 -0500
> Not really. If they want a real contest. Make a 10k doucument
> encrypted with a secret key. And offer someone 10 million dollars state
> and federal government tax fee if they can decrypt it
> it in a years time. Will they do that. Hell no someone might
> break it. And they don't want anyone to break it.
If you're smart enough to break the cipher, you sure as hell wouldn't take
the 10 million. That is peanuts compared to what you could make if you knew
that you could break all "secure" documents of the future for ~20 years.
Jeff
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: Tue, 03 Oct 2000 09:01:50 -0600
"John A.Malley" wrote:
>
> David Wagner wrote:
<snip>
> > And, in real life, everyone uses random padding, and the random padding is
> > large enough to avoid Coppersmith's attack.
>
> With e = 65537 the padding can be smaller than the padding required for
> e = 3 while maintaining resistance against Coppersmith's Short Pad
> Attack. Since less bits in the string to encrypt must be random pad
> more bits in the string can be message bits - and thus there is more
> bandwidth for the message. Isn't this a point in favor of using e =
> 65537?
<snip>
Almost no one uses RSA to encrypt "messages" per se; instead they
use the conventional scheme of encrypting the message with a
symmetric cipher, then encrypt the symmetric key with RSA. Note
that the symmetric key is already much smaller than the RSA
encryption size (for a single encryption). Thus, there is in
fact already a surplus of RSA bandwidth, and there is no virtue
in attempting to squeeze more info in. Indeed, the higher the
security level, the more true this is (RSA size increases much
faster than the symmetric key size).
If you can think of a (real) situation in which the RSA bandwidth
actually matters, that would be of interest.
I don't think that D Wagner is actually proposing that we
forget about the attacks on small RSA exponents. Instead he
is questioning the "conventional wisdom" or "rule of thumb"
for using larger exponents in real life - when in real life
he can't see any real attacks.
JM
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
