Cryptography-Digest Digest #352, Volume #14 Mon, 14 May 01 12:13:01 EDT
Contents:
Re: [Q] About HMAC(Keyed-Hashing for Msg Auth) (Mark Wooding)
Re: What Is the Quality of Randomness? (Tim Tyler)
Re: Security proof for Steak ("Henrick Hellstr�m")
Re: Comparison of Diff. Cryptanalysis countermeasures (Mark Wooding)
Re: About DES or AES ? (Paul Crowley)
Re: which public key algorithm is easy & gd to use? (DJohn37050)
Re:My algorithm and problem ([EMAIL PROTECTED])
Re: ISO 9796-1:1991 (Shai Halevi)
Re: Not a realistic thing to do......Why? (Keill Randor)
Re: OAP-L3: "The absurd weakness." (James Felling)
Re: Comparison of Diff. Cryptanalysis countermeasures (Paul Crowley)
Avoiding RSA padding altogether? (Paul Crowley)
Re: Security proof for Steak ("Henrick Hellstr�m")
Re: Cryptanalysis Question: Determing The Algorithm? (James Felling)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: [Q] About HMAC(Keyed-Hashing for Msg Auth)
Date: 14 May 2001 13:24:40 GMT
Young Sang Kang <[EMAIL PROTECTED]> wrote:
> Hi.
>
> In RFC2104(HMAC: Keyed-Hashing for Message Authentication),
> ipad and opad are defined like this
> ipad = the byte 0x36 repeated B times
> opad = the byte 0x5C repeated B times.
>
> I'm curious to know whether 0x36 and 0x5C are magic numbers or not.
There's nothing especially important about the numbers. Both have
Hamming weight 4, and the Hamming distance between them is also 4, but I
suspect that's just a result of paranoia. Any pair of distinct bytes
ought to do as well, I'd have thought.
The padding step exists to make the chaining value to the subsequent
hashing steps be random. In this way, HMAC can benefit from the
security reduction from breaking NMAC to finding collisions in the
underlying hash function with unknown IV.
-- [mdw]
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: What Is the Quality of Randomness?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 14 May 2001 13:18:49 GMT
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
: There is no such thing as a random sequence, only a random source.
Well, "random sequence" is a meaningul term - provided one uses the notion
of randomness that derives from Chaitin and Kolmogorov, rather than from
Shannon.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Security proof for Steak
Date: Mon, 14 May 2001 15:31:48 +0200
"Benjamin Goldberg" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> Henrick Hellstr�m wrote:
> >
> > "Benjamin Goldberg" <[EMAIL PROTECTED]> skrev i meddelandet
> > news:[EMAIL PROTECTED]...
> > > Henrick Hellstr�m wrote:
> > The table in the source code is the expansion of a 32x32 linear bit
> > matrix, so that only four lookups will be needed for each 32 bit input
> > (one for each byte of the input). The design rationale for choosing
> > that particular matrix is purely empirical, but it might be re-created
> > in a few steps:
> > a) Start with the 4x4 MDS matrix of TwoFish.
> > b) Apply a quadruple of s-boxes so that the matrix degenerates into a
> > 32x32 invertible bit matrix over GF(2).
> > c) Transpose the rows and then the columns of the 32x32 matrix
> > according to a pair of constant permutations.
>
> How much code would it take to do this? How does that compare to the
> size of writing the tables into your source directly?
I estimate that you would get the least total amount of code (incl. constant
tables) by generating the table on the fly from a 32 element vector of 32
bit elements. The procedure I describe above seems to require that you
expand the TwoFish MDS matrix to a 4 times 256 element matrix of 32 bit
elements, then sort that matrix, extract the elements corresponding to input
2^0, 2^1, 2^2 etc, and finally permute and transpose those elements.
> You've explained it only partially. You haven't said what those four
> sboxes are, and you haven't said what the permutations are.
The four s-boxes are uniformly distributed random single cycle permutations,
provided that you use a sufficiently large key. Otherwise the s-boxes are
uniformly distributed pseudo random single cycle permutations, obtained by
expanding the user key to a sufficiently large key at the beginning of the
key schedule. For the purpose of key expansion, Steak (the TDefaultSteak
class in the reference code) with a constant key is used as pseudo random
bit generator. (I am not entirely satisfied with this construction, but as
far as I can see it is sufficiently secure.)
> > > How the bleep do I know that they
> > > aren't some sort of back door?
> >
> > You don't. It is impossible to prove that there is no backdoor. But a
> > partial justification would be the fact that Steak uses random single
> > cycle s-boxes, and as far as my imagination goes it is impossible that
> > any back door into the linear matrix would be there for any internal
> > key data and any vector size. Basically, what I am saying is that
> > there might be (small) sets of weak keys, but not really any back
> > door.
>
> Is there a distinguisher for these weak keys?
Well, I guess so, but I am frankly still trying to find both any weak key
and the most efficient distinguisher for any such key. Very informally
speaking, the combined effect of the s-boxes corresponding to such a key
would resemble a 32 bit transposition. Such keys would be characterized by a
relatively modest avalanche both internally in the function F_m and in the
promotion from F_m to F_{m+1} (cf. the security proof at
http://www.streamsec.com/sattacks.asp ). This might result in a
recognizeable pattern in the relation between the image and pre-image of F_m
over a large number of m. But you should also note that no such key would
make Steak weaker than the DefaultSteak algorithm that doesn't feature any
s-box at all, and as far as I can tell DefaultSteak is a pretty decent PRG.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Comparison of Diff. Cryptanalysis countermeasures
Date: 14 May 2001 13:45:16 GMT
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> There appear to be two commonly used methods for diff. cryptanal.
> hardening
> for block ciphers:
>
> 1. Carefully design the S-boxes. This seems to come down
> to trying to obtain the flattest difference distribution
> possible while minimizing the non-zero entries in the
> first column of the diff. distribution table. I haven't
> fully figured out how this is done but I understand
> why this is done.
>
> 2. Use decorrelation which can offer "provable resistance"
> to diff. attacks.
3. Design diffusion layers in your cipher to maximize the number of
active S-boxes in any differential through the cipher. This is the
`wide-trail strategy', used for example in Square and Rijndael.
-- [mdw]
------------------------------
Subject: Re: About DES or AES ?
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Mon, 14 May 2001 14:52:57 GMT
[EMAIL PROTECTED] (Mark Wooding) writes:
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> > Simple. They both have inverses. All invertable functions are
> > permutations.
>
> Wrong. A permutation is a bijective function where the domain and range
> are the same set.
>
> Consider the function from F_{2^8} to Z/256Z defined by the map f |->
> f(2) + 256Z. It's clearly bijective (think about it for a little bit)
> but just as clearly not a permutation. It translates, invertably,
> between apples and oranges.
This is a pretty subtle distinction - thanks for clarifying it!
Actually, it's less subtle if you consider infinite sets. Cantor
defines a bijection between the natural numbers and the rationals;
this clearly isn't a permutation.
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
"Conservation of angular momentum makes the world go around" - John Clark
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 14 May 2001 14:55:09 GMT
Subject: Re: which public key algorithm is easy & gd to use?
I would say that DSA/DH is the easiest to understand. RSA has lots of tricky
stuff in key gen and it needs to be all kept secret, while DSA/DH simply uses a
random number in the correct interval as a private key and does the basic
arithmetic operation (MODEXP) to calculate the public key. It also is MUCH
easier to VALIDATE the resulting pubic key to ensure that they were no
arithmetic boo boo's.
Don Johnson
------------------------------
From: [EMAIL PROTECTED]
Subject: Re:My algorithm and problem
Date: 12 May 2001 06:53:24 GMT
Hi,
Thank you for your reply. Here is some code I am actually using in my
application. They are stronger than the one I posted. Please re-view
here passwords are stored in
int FPassword[FPwdLength];(32bit int)
void GenerateChaosSequence(int factor, int pos, int length, int
SecurityLevel)
{
int i, j, temp;
for(i=0;i<length;i++)
{
temp=factor+pos+i; Place B
for(j=0;j<SecurityLevel;j++)
temp=(int)floor(cos(temp)*POW2_42);
FChaosSequence[i]=(char)temp; Place A
}
}
when
reading&writing:
for(pass_no=0;pass_no<FPwdLength;pass_no++)
{
GenerateChaosSequence((FPassword[pass_no]+FChaosFactor[pass_no])*(pass_no+1),
FileStream->Position, BufferRead, FSecurityLevel);
for(i=0;i<BufferRead;i++)
((char*)FBuffer)[i]+=FChaosSequence[i];
}
As to the problem that the cos may not produce the stable effect. I've tested
it in my PC. No matter how large the file is, the result is stable. I will
test it on different PCs with different CPUs later.
There is also a way to solve the problem anyway. Just use a valve to judge
whether each call to cos may produce unstable effect in the algorithm.
(in the above code, judge whether temp at Place A is in the range of
N-0.00001,N+0.00001,N is integer)
If yes, a tag is stored into the encrypted stream, so when decrypting the
algorithm will ignore such possible unstable calls to cos. Besides 0.1 will
be added to temp at Place B until a stable effect can be produced.
>Again this suffers from several problems. 1234567890 =
>(2)*(3)^2*(5)*(3803)*(3607) none of which are 256 in fact 1234567890 mod 256
>= 210 which means 210 symbols are more frequent then others.
Maybe. But it is not that meaningful I think because 1234567890 is big
enough.
By the way, someone told me there is an cryto algorithm called FLINT. Who
knows it? Can you tell me where I can find it? I tried searching for it
online. But failed.
Best wishes,Yan.
[EMAIL PROTECTED]
----original-----
> Hi,
> Below is a brief description of my data encryption algorthm(simplified form
> here) and my question. Please help to evaluate my algorithm and answer my
> question. Thanks.
>
> INPUT:
> char Data[10000];
> int Password;
> (here int means 32 bit int)
Right away that's a problem if long term or even modertate term security is
required.
> OUTPUT:
> char SecretData[10000];
>
> Encryption Algorithm:
>
> 1. Generate a sequence from the password, which has the same length as the
> Data and should has the largest entropy:
>
> for(i=0;i<10000;i++)
> Sequence[i]=int(cos(i+Password)*1234567890) mod 256
Again this suffers from several problems. 1234567890 =
(2)*(3)^2*(5)*(3803)*(3607) none of which are 256 in fact 1234567890 mod 256
= 210 which means 210 symbols are more frequent then others. Second you
must ensure that all implementations give the exact same result for cos.
Most will not (to 10 digits perhaps... I dunno) otherwise the stream is
broken.
Also your effect key space is only 2pi anyways. Try cos(i + 2npi) the
cosine is the same for all values of 'n' and fixed 'i'.
So your effective keyspace is only really 0,1,2,3,4,5,6 or 7 values or so.
So it's not a 32-bit key anymore it's a 3-bit key.
<snip>
TOm
----- Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web -----
http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: Shai Halevi <[EMAIL PROTECTED]>
Subject: Re: ISO 9796-1:1991
Date: Mon, 14 May 2001 11:48:25 -0400
ISO 9796-1 was withdrawn because it is (badly) broken. See details in
the paper "A Chosen Messages Attack on the ISO/IEC 9796-1 Signature
Scheme" by Fran�ois Grieu, in Eurocrypt'2000, LNCS 1807, Springer,
2000, pp. 70-80.
Are you sure you want to implement it? It may be a security problem.
Regards,
-- Shai
Uwe Guenther wrote:
> Hello,
>
> I have to implement an client that uses german HBCI-Protocol
> (HomeBankingComputerInterface). There are references to
> the ISO 9796-1:1991(formating and signing). Since this standard
> are withdrawn, there is no way to get the standard from ISO.
>
> Has some one any ideas where I can get the withdrawn ISO standard.
> I know that there some security problems with the use of the standard.
> But there is now other way to implement HBCI.
>
> --
> Uwe
> mailto:uwe_at_cscc_dot_de
------------------------------
From: Keill Randor <[EMAIL PROTECTED]>
Subject: Re: Not a realistic thing to do......Why?
Date: Mon, 14 May 2001 14:55:11 +0000
>Real ciphers are designed long the lines of fixed keys and fixed cipher
>design per message. (well typically the cipher design won't change at all).
>The security is suppose to lie in the key nothing more.
>
>And real cryptographers never compare their ciphers to an OTP since it's not
>a realistic thing todo. Sure there is no break against Rijndael faster than
>searching the key, that doesn't make it an OTP though....etc.
>
>Tom
>
It looks like the system I have is a lot more powerful than I first thought, then.....
I AM comparing the system I have to an OTP, and it IS realistic to do so.
If you want security, then ANY system that is crackable, as far as I am concerned, is
not good enough. (Granted, I am not a good enough mathematician to make much of a
dent in PKI, though if I got together with a decent mathematician and a programmer, we
might be able to work something out). As for symmetrical systems, though, as far as I
am concerned if it's crackable its not very good....
I need to get the system I have made into a program, and see just how fast it really
is, at it's most basic. (It pretty nmuch is an OTP) - (It'll still be far more secure
than Rijndael).
Hmmm, any one know any decent mathematicians and programmers in England, who might be
interested????
Keill Randor
[EMAIL PROTECTED]
_______________________________________________
Submitted via WebNewsReader of http://www.interbulletin.com
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: "The absurd weakness."
Date: Mon, 14 May 2001 10:54:13 -0500
Anthony Stephen Szopa wrote:
> James Felling wrote:
> >
> > Tom St Denis wrote:
> >
> > > "Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]...
> > > > Tom St Denis wrote:
> > > > >
> > > > > "Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
> > > > > news:[EMAIL PROTECTED]...
> > > > > > With your many previous vague and less than precise posts you must
> > > > > > explain exactly what YOU mean by "leakage."
> > > > > >
> > > > > > Not what "leakage" has been defined by others but in your own words
> > > > > > what you understand this word / concept to mean.
> > > > > >
> > > > > > There can be no discussion on what YOU mean by "leakage" unless
> > > > > > you define it in your own terms because you frequently are ambiguous
> > > > > > and we cannot assume that you even know what you mean.
> > > > >
> > > > > Leakage means what it implies. Every output byte must leak some
> > > (perhaps
> > > > > little) info about the input state, this is always going to happen.
> > > > >
> > > > > The real question is how much info is leaked, i.e how many bytes (bits,
> > > > > etc...) are required to learn enough about the internal state.
> > > > >
> > > > > Tom
> > > >
> > > > I think the place to start in answering this question is to read the
> > > > Help Files: Theory, Processes, Operation, etc. and the recommended
> > > > use.
> > > >
> > > > Good luck. You'll need it if you think you have a prayer in
> > > > breaking the OTP files.
> > >
> > > Um that's your job not mine. You want to show how secure it is, you should
> > > come up with attacks on the system.
> > >
> > > Tom
> >
> > Simply put: groups. This means that given any k1 and any k2 there exists a k3
> > such that F(k1,F(k2,X)) = F(k3,X). This means that aplying that method N times
> > will give exactly the same level of security as applying it once. ( the proof
> > is left as an example for the student).
> >
> > All of the methods I havbe seen are groups or special cases of a more generic
> > permuting method that is a group, and many of them are groups with other
> > methods. This means that taking a method and using it over and over again is no
> > more secure than the generic group operation that it is a special case of.
> >
> > Worse, some of the methods will comute. This menas F(k1,G(k2,X))=
> > G(k2,F(k1,X).This is a weakness because it means that if only those two methods
> > are used in whatever pattern you wish you are no better off than using them (or
> > their generic equivalent) once.
> >
> > Some of the methods have fixed points. Data that that method cannot and will
> > not alter. This means that you must alter the data by annother method. Yes,
> > every data point can and will be adjusted by some process, but since some
> > methods have fixed points it will produce a bias in the data at those fixed
> > points.
> >
> > I have pointed this out to you in the past, and while I do accept that using
> > your medhods over and over again you can and will eventually get good data, it
> > requires more work to get to that point than it would with a conventional
> > stream cypher.
>
> Are you are under the delusion that the OTPs are derived directly
> from the random digit output?
No. I am of the opinion that the documentation on your website as to the methods used
in generating the raw data that the OTP's are derived from is accurate. If so, the
"methods" that you mention have the characteristics that I have described. If this
document is not an accurate portrayal of your system, please let me know. If the
"methods" listed are indeed used as the document suggests, and work as indicated, the
weaknesses I point out do exist. If not please correct the documentation so that I
may accurately evaluate your system.
I do acccept that security can be obtained via your system, but I also maintain that
your system makes you REALLY work hard for it.
An example for free of the fixed point property. the operation "Mix a mix file" in
your documentation has the property that
Mixamix(set(1+105*n))=set(1+105*n) for all n with probability 1(always true)
Worse yet, this operation is a subset of a group( 105 element permutations with the
property listed above). Which means this property holds even after applying mixamix
over and over and over again and again even if your inputs for all of them are
different.
Every one of the "methods" listed has some similar flaw. yes, these can be gotten
around by mixing them up, and alternating them, but they still do not produce
randomness as efficiently as you think.
------------------------------
Subject: Re: Comparison of Diff. Cryptanalysis countermeasures
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Mon, 14 May 2001 15:54:53 GMT
[EMAIL PROTECTED] (John Savard) writes:
> I'd tend to agree that key-dependent S-boxes may provide protection
> against more than differential cryptanalysis. But of the methods that
> _do_ provide this protection, key-dependent S-boxes are certainly
> easier to understand by nontechnical people than most of the other
> methods.
Not sure this is so: if you can get your head around DC at all,
understanding the proof at the back of the Rijndael paper should be a
doddle...
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
"Conservation of angular momentum makes the world go around" - John Clark
------------------------------
Subject: Avoiding RSA padding altogether?
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Mon, 14 May 2001 15:54:54 GMT
Something I wondered while reading the descriptions of OAEP and PSS.
Is there a simpler way to ensure that the input to RSA is unstructured
and fairly pseudorandom, by moving away from thinking of it as
"padding" altogether?
For encryption, it seems like something akin to DHAES would be
applicable to RSA: choose a random number R fairly between 0 and N-1
(where N is the RSA modulus), encrypt R using RSA without padding and
send that as a header, and use Hash(R) as a secret key to encrypt and
MAC your message. For signing, seed a CPRNG with the hash of your
message and a nonce, use the CPRNG to choose a pseudorandom number
fairly between 0 and N-1, then sign that without padding.
If the hash function and CPRNG are strong, this would seem to
eliminate all the structure that chosen ciphertext attacks and
suchlike depend on; every query to a decryption oracle either tells
you what you already knew (if you encrypt in the normal way) or says
"MAC failure, bad message" (if you try and cook your ciphertext).
Of course, OAEP and suchlike are accompanied by proofs of security, so
the schemes I'm discussing here would need similar proofs to be worth
considering. I hold out the hope that such proofs could be simpler
than those for comparable schemes. But I'd appreciate a brief first
glance from those familiar with such schemes, to tell me whether this
is obvously broken, already proposed and shot down, or otherwise not
worth pursuing. Thanks!
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
"Conservation of angular momentum makes the world go around" - John Clark
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Security proof for Steak
Date: Mon, 14 May 2001 18:03:40 +0200
"Benjamin Goldberg" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> Henrick Hellstr�m wrote:
> > The table in the source code is the expansion of a 32x32 linear bit
> > matrix, so that only four lookups will be needed for each 32 bit input
> > (one for each byte of the input). The design rationale for choosing
> > that particular matrix is purely empirical, but it might be re-created
> > in a few steps:
> > a) Start with the 4x4 MDS matrix of TwoFish.
> > b) Apply a quadruple of s-boxes so that the matrix degenerates into a
> > 32x32 invertible bit matrix over GF(2).
> > c) Transpose the rows and then the columns of the 32x32 matrix
> > according to a pair of constant permutations.
>
> How much code would it take to do this? How does that compare to the
> size of writing the tables into your source directly?
>
> You've explained it only partially. You haven't said what those four
> sboxes are, and you haven't said what the permutations are.
Oh, you mean the s-boxes and transpositions that will get you from the
TwoFish matrix to the Steak matrix?
1. The s-boxes are easy to represent in code: Expand the TwoFish MDS matrix
to it's 4 times 256 dword representation. Sort each of the four rows of this
table. (Three of the rows should be sorted using regular arithmetic
comparison. The second row has to be sorted modulo 2^16.) The resulting
table is such that the elements [i,2^j] will generate the entire table.
(Hm!? Could this fact be used in a differential attack on TwoFish? Perhaps
if the key space is expanded carelessly.))
2. The transposition of the columns of the bit matrix was the "black box"
output of an experimental comparison of different permutations. Its map
representation is <0 8 9 16 2 24 25 17 10 18 26 11 2 19 27 3 28 4 20 29 21 5
12 13 22 30 6 7 14 15 23 31>. The transposition of the rows was a rotate
right by one. (A clarification: The row transposition, i.e. the ror by one
of the table values, was applied prior to the column permutation.)
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Cryptanalysis Question: Determing The Algorithm?
Date: Mon, 14 May 2001 11:05:41 -0500
"Bo D�mstedt" wrote:
> Even though this is sci.crypt, let's try a systematic approach:
>
> Can we prevent the cryptanalyst from learning which
> cipher algorithm that we use?
>
> If we do, how much can we gain?
The gain at best of having a set of 2^n possible cyphers to choose from is
at best 2^n bits. The reasons behind this is that parallell searches can be
done, each assuming that a given subalgorithim is in use.
>
>
> First, we need a sufficiently large algorithm space (to prevent serial
> or parallel search as discussed above). We have seen (indications on)
> that this is no problem, but I feel that most readers don't think that
> this is obvious at all. This is due to that most conventional block
> ciphers are iterated substitution/transposition ciphers, and what
> else can possibly exist??
>
> Second we must prevent the cryptanalyst from learning which algorithm
> we are using. We may use physical protection means, and zero out
> the algorithm, when a physical attack is detected on a cipher machine.
> (This function is advantageous anyway, and is required in FIPS 140-2
> level 3-4 compliant implementations).
Agreed, but we can also assume the opostion can ans will get hold of several
such devices, and will eventually break it -- you cannot assume that it
remains secure over time.
>
>
> We may, however, annoy the cryptanalyst by using several cipher
> algorithms. We may even select cipher algorithms on the fly, possibly
> as a function of the IV (or similar arrangement...).
Agreed. However, your recipient also needs to have all the information you
used available to him, so a break vs. one system could in all probability be
extended to weaken all other methods.
>
>
> The size of the set of possible cipher algorithms, that we can select
> from, will be limited to maximum available entropy. How much entropy
> do we have, when encrypting? What algorithm space would that
> correspond to, for a communication network? We note that if the
> entropy level is estimated to be insufficient, we may use a hardware
> random number generator to reach any level of entropy.
> (Now the AD: http://www.protego.se/sg100_en.htm)
>
> * * *
>
> [EMAIL PROTECTED] wrote:
> > I was giving a talk today about cryptography for my coworkers, and the
> > question came up: If someone gets a chunk of cyphertext that they are
> > trying to cryptoanalyze, how do they determine what algorithm was
> > used, and does that even matter?
>
> We see that not only will the cryptanalyst possibly have problems
> cryptanalysing an unknown system (how much can we gain?),
> but we cannot rule out actual working implementations that use
> unrecoverable algorithms, based on limitations on algorithm
> space and entropy.
>
> What other limitations can there be?
> And how much can we gain?
2^n possible methods(assuming all are "strong") will add n-bits of key
strength, as will encryping the output of one "strong" cypher with annother
"strong" cypher that is not a group with the original. ( I prefer the second
method to the first -- less stuff to keep track of.
>
>
> Bo D�mstedt
> Chief Cryptographer
> Protego Information AB
> Ideon Gamma Science Park
> SE - 223 70 Lund
> SWEDEN
> http://www.protego.se
------------------------------
** 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
******************************
