Cryptography-Digest Digest #90, Volume #12 Fri, 23 Jun 00 02:13:01 EDT
Contents:
Re: Compression and known plaintext in brute force analysis (restatements caused by
the missing info .... thread) (zapzing)
Re: how to compare the securtity between ECC and RSA (DJohn37050)
Certify v1.0 Released (Almost-freeware PKI library for C++) (denis bider)
Re: how to compare the securtity between ECC and RSA (Roger Schlafly)
Re: how to compare the securtity between ECC and RSA (Roger Schlafly)
Re: Comments/analysis requested (Samuel Paik)
Re: DH - Man In The Middle (lcs Mixmaster Remailer)
Re: Comments/analysis requested ([EMAIL PROTECTED])
Re: Linear Feedback Shift Register *with* lock-up? ("Trevor L. Jackson, III")
Re: Variability of chaining modes of block ciphers (Tim Tyler)
Re: Encryption on missing hard-drives ("Trevor L. Jackson, III")
Re: Weight of Digital Signatures (Robert Stonehouse)
Re: Comments/analysis requested (David A. Wagner)
Re: small subgroups in Blum Blum Shub (David Hopwood)
Re: MD5 Expansion (David Hopwood)
AES key lengths (David Hopwood)
Re: Variability of chaining modes of block ciphers (David Hopwood)
Scholarship available to study Information Security at RMIT University
([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Compression and known plaintext in brute force analysis (restatements
caused by the missing info .... thread)
Date: Fri, 23 Jun 2000 00:08:24 GMT
And another problem: suppose a random (or already encrypted)
file is encrypted. Then an amount of predictable
information will be added to a file that was previously
perfectly unpredicatble.
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: how to compare the securtity between ECC and RSA
Date: 23 Jun 2000 00:27:25 GMT
Yes, current estimates of space needed to attack RSA keys indicate this. But
what if the algorithm advances to use less space? If you just count time and
not space, you get a more conservative estimate.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (denis bider)
Subject: Certify v1.0 Released (Almost-freeware PKI library for C++)
Date: Fri, 23 Jun 2000 00:31:35 GMT
Hello folks,
Certify v1.0 has been released: http://www.globera.com/certify.php3
For those of you not yet in the know: Certify is a C++ library, based
on Wei Dai's excellent Crypto++, which makes it easy for a C++
developer to:
- handle digital certificates, certificate requests and the rest of
Crypto-ASN.1
- access and manipulate information on PKCS#11 cryptographic tokens
(currently tested with ActivCard Gold smart cards)
Classic Example I - load an X.509 certificate and print issuer's DN:
Certify::ASN::Certificate cert(
CryptoPP::FileSource("the-verisign-trial-cert-i-exported-from-internet-explorer.cer",
true)
);
std::cout << cert.tbs.issuer;
Classic Example II - load PKCS#11 DLL, login into the PKCS#11 token
inserted in Reader 1 and find all private keys on the token:
TokenPP::Library cryptoki =
PKCS11Provider::LoadCryptoki("acpkcs.dll", false);
TokenPP::Session session =
cryptoki.GetSlotList()[0].OpenSession(true);
session.Login(TokenPP::UserNormal, "passphrase");
std::vector<TokenPP::Object> privatekeys =
session.FindObjects_Class(TokenPP::ObjClassPrivateKey);
The library is ContributionWare - we actually make it possible for
people who contribute to the library to get real and fair financial
compensation for their efforts. The library is free for non-commercial
use, whereas commercial licenses sell for peanuts.
Visit http://www.globera.com/certify.php3 to download or to get more
information.
Kind regards,
denis bider
//
// denis bider
// globera d.o.o., Ljubljana, Slovenia
// http://www.globera.com
// +386 1 510 7740
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: how to compare the securtity between ECC and RSA
Date: Thu, 22 Jun 2000 18:34:14 -0700
DJohn37050 wrote:
> But
> what if the algorithm advances to use less space? If you just count time and
> not space, you get a more conservative estimate.
And if the algorithm advances to use less time but the same space?
Then you get a more conservative estimate by just counting space
and not time.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: how to compare the securtity between ECC and RSA
Date: Thu, 22 Jun 2000 18:43:57 -0700
Joseph Ashwood wrote:
> I always found the chicken without a head method to be the most
> conservative. We've all seen it, the one where the person decides that they
> want a 400Mbit RSA key that is replaced every hour, used exclusively for
> their low security communications, ...
Yes, that would be silly.
> So right now in PGP I use a 4096 bit DH/DSS public key
> that I tend to replace annually, ...
Either you are extremely paranoid or you have some secrets
that need 100+ year protection. Personally, it is about 10x
the key size I need.
------------------------------
From: Samuel Paik <[EMAIL PROTECTED]>
Subject: Re: Comments/analysis requested
Date: Thu, 22 Jun 2000 19:09:50 -0700
For those who don't want to try to decode Wayne's code, I believe
the following is a good representation of his encryption
unsigned long key[16];
unsigned long text[16];
for (idx = 0; idx < 16; idx++)
{
unsigned long keyw = key[idx];
unsigned long text0 = text[idx];
unsigned long text1 = text[keyw&0xf];
text[keyw&0xf] = ((text1 & keyw) | (text0 & ~keyw)) + keyw;
text[idx] = ((text0 & keyw) | (text1 & ~keyw)) + keyw;
}
Basically, the low four bits of a key word selects a word from the
work text, then the bits are exchanged between the two words using
the key word as a mask, and then the key word is added in to both.
This does not seem very secure to me, but not trivially breakable.
Once the low order bits of the key words are determined (there
are 64 bits), the rest of the key bits appear to be trivially
unravelled.
--
Samuel S. Paik | http://www.webnexus.com/users/paik/
3D and multimedia, architecture and implementation
------------------------------
Date: 23 Jun 2000 02:40:27 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: DH - Man In The Middle
Mark Wooding writes:
> p_S, q_S, g_S -- DSA parameters for the server. (q_S is 2t-bit prime;
> p_S is a larger prime such that q_S divides p_S - 1, and the
> Discrete Log Problem mod p_S is hard; g_S generates the
> order-q_S subgroup mod p_S.)
>
> p, q, g -- DH parameters for key exchange. (p = 2 q + 1; both p and q
> are prime, and p is large enough for the Discrete Log Problem
> mod p to be hard; g = 4.)
Why not reuse the DSA p/q/g for the DH? Since t is your security
parameter, attacks against the DH key should be just as difficult as
attacks against the DSA key. (One caution, it is necessary to check
that the exchanged DH values are subgroup members when a subgroup is
used for the DH.)
This would allow you to use some of the shortcut authenticated key
exchange methods, some as the MTI protocol. In that system the two
sides have private keys x1 and x2, and public keys y1=g^x1 and y2=g^x2.
Each computes a random value for the DH, k1 and k2, and they exchange
g^k1 and g^k2. For the shared secret they compute g^(x1*k2 + x2*k1),
which equals (g^k2)^x1 * y2^k1 and also y1^k2 * (g^k1)^x2, so each
side can compute it.
Then they do a short exchange where each side tests that the other
can encrypt/decrypt some standard value using this shared secret key.
The fact that each side ended up with the same shared key shows that
they knew the appropriate secret values, hence authenticating them.
For the case where only one side has a long term public key, say y1=g^x1,
you could use something like g^(k2*(k1+x1)) for the shared secret.
This would give the client assurance that it is talking to the right
server, after confirming that it shared the same secret value.
One problem with this approach is that the security parameter t may
be different for the signatures than for the encryption. Forging a
signature is often a more expensive and risky attack. It may require
real-time packet interception and substitution, which would be a difficult
proposition for many attackers. 80 bits of security may be enough when
added to the expense of mounting an active MITM attack. However breaking
the DH key can be done passively and only requires snooping, so you may
want a somewhat higher security level.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Comments/analysis requested
Date: Fri, 23 Jun 2000 02:44:58 GMT
In article <[EMAIL PROTECTED]>,
Samuel Paik <[EMAIL PROTECTED]> wrote:
> For those who don't want to try to decode Wayne's code, I believe
> the following is a good representation of his encryption
>
> unsigned long key[16];
> unsigned long text[16];
>
> for (idx = 0; idx < 16; idx++)
> {
> unsigned long keyw = key[idx];
> unsigned long text0 = text[idx];
> unsigned long text1 = text[keyw&0xf];
>
> text[keyw&0xf] = ((text1 & keyw) | (text0 & ~keyw)) + keyw;
> text[idx] = ((text0 & keyw) | (text1 & ~keyw)) + keyw;
> }
>
> Basically, the low four bits of a key word selects a word from the
> work text, then the bits are exchanged between the two words using
> the key word as a mask, and then the key word is added in to both.
>
> This does not seem very secure to me, but not trivially breakable.
> Once the low order bits of the key words are determined (there
> are 64 bits), the rest of the key bits appear to be trivially
> unravelled.
> --
Samuel,
Thank you very much for the translation. It looks much more
understandable the way you wrote it <g>. By 64 bits, do you mean the
low four bits of each of the 16 words?
Thanks, Wayne
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Linear Feedback Shift Register *with* lock-up?
Crossposted-To: comp.theory,sci.math
Date: Wed, 21 Jun 2000 01:34:36 GMT
bubba wrote:
> The book "Shift Register Sequences" is back in print now.
>
> http://shop.barnesandnoble.com/booksearch/isbnInquiry.asp?userid=1L52CNM1BQ&;
> mscssid=S18WX4RX86S92PJS00A3HCP45E5U3GL4&srefer=&salesurl=Rshop.barnesandnob
> le.com/booksearch/results.asp&isbn=0894120484
The blurb on that page is a bit eclectic:
"bn.com customers who bought this book also bought:
Vittorio the Vampire: New Tales of the Vampires, Anne Rice
River's End, Nora Roberts,Fowler
Hannibal, Thomas Harris"
>
>
> "Ponder" <[EMAIL PROTECTED]> wrote in message
> news:8iocit$1ghu$[EMAIL PROTECTED]...
> > I'm looking to use a Linear Feedback Shift Register to implement
> > a counter with minimal resources (i.e. fewer gates and wires than
> > an additive incrementor). I've seen quite a bit of cryptographic
> > literature on how to use an N-bit LFSR to count through (2^N)-1
> > values before repeating. There is one value (usually all 0's or
> > all 1's) where the LFSR would be "stuck" at the same value as
> > it counts.
> >
> > What I'm really looking for, though, is an LFSR that counts
> > through 2^N values and then *does* get stuck in the last state.
> > This way when I find it stuck, I would know that it counted through
> > all the values since its initial state. There would be one
> > "minimal" value for the initial state, that would cause it to
> > count through all 2^N values before sticking; if I want to count
> > fewer steps I would pick an initial value further along the
> > sequence.
> >
> > Does anyone out there know how to do this? I've looked at some
> > of the polynomial theory on LFSR's, but guess that it only
> > applies to counters that actually loop through a sequence rather
> > than iterating through a sequence and looping on a final value.
> >
> > Also, is there a good algorithm for converting the elements of
> > an LFSR sequence into the actual value of the count? (Or more
> > precisely, for mesuring the number of iterations between two
> > values). For small N you could just count through the sequence
> > until you find a match, but I'm interested in N around 32 or 64
> > so this would take too long.
> >
> > Thanks in advance,
> >
> > Carl Ponder
> > [EMAIL PROTECTED]
> >
> > --
> >
> > <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
> > Carl Ponder, Ph.D. Carl Ponder [EMAIL PROTECTED]
> > AIX Performance Tools IBM Server Division Phone: (512) 838-1638
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Reply-To: [EMAIL PROTECTED]
Date: Fri, 23 Jun 2000 02:38:38 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Eric Lee Green wrote:
:> Mok-Kong Shen wrote:
:> > [...] By combinatorics this gives 8 variants.
:>
:> Great. You just added 3 bits to the key space. At the expense of adding yet
:> more code that could be defective/insecure [...]
: If you use CBC, then switching to PCBC (using both plaintext and
: ciphertext) may result in a difference more than what can easily be
: quantified by bits.
Why can't the attacker just split his resources and attack both ways?
Using one of two types of chaining mode won't add more than 1 bit to the
keyspace.
: Chaining is in fact very simple to implement. So neglecting the
: benefit it offers is not economically justified in my humble view.
There *are* costs. You can no longer encrypt blocks in parallel, for
example.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
Date: Fri, 23 Jun 2000 01:09:05 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Encryption on missing hard-drives
Then you aren't runing 32-bit Windoze (AKA NT).
jungle wrote:
> another urban myth ...
> I'm running stable system for years now ...
>
> "Trevor L. Jackson, III" wrote:
> > On the 32-bit versions of Microsoft(tm) Windows(!tm) you cannot disable the
> > swapfile because the memory management subsystem goes through the disk
> > subsystem. If you disable swapping the system becomes (ahem) "unstable".
>
> another urban myth ...
> I'm running stable system for years now ...
------------------------------
From: [EMAIL PROTECTED] (Robert Stonehouse)
Subject: Re: Weight of Digital Signatures
Date: Fri, 23 Jun 2000 05:29:20 GMT
[EMAIL PROTECTED] (John Savard) wrote:
...
>A law that makes a digital signature "just as binding as one in ink",
>when it is so much easier to break into someone's house and read their
>hard drive than forge their signature perfectly makes ordinary people
>much more vulnerable to forgery than before.
...
The thing that makes an ink signature binding is the fact that it
was written by the right person. If your bank pays out on a forged
cheque, saying 'Well, it was a perfect forgery' won't help the bank
at all. The bank has to make it good to you.
It is hard to imagine how any law authorising digital signatures can
preserve that protection for bank customers and others who sign
documents.
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Comments/analysis requested
Date: 22 Jun 2000 21:44:39 -0700
In article <[EMAIL PROTECTED]>,
Samuel Paik <[EMAIL PROTECTED]> wrote:
> unsigned long key[16];
> unsigned long text[16];
>
> for (idx = 0; idx < 16; idx++)
> {
> unsigned long keyw = key[idx];
> unsigned long text0 = text[idx];
> unsigned long text1 = text[keyw&0xf];
>
> text[keyw&0xf] = ((text1 & keyw) | (text0 & ~keyw)) + keyw;
> text[idx] = ((text0 & keyw) | (text1 & ~keyw)) + keyw;
> }
Thanks for the C code! That's much more understandable.
This cipher appears to be easily breakable, with some known text.
I strongly recommend to avoid this cipher.
First, note that the least significant bit (LSB) of each of the 16
words of the ciphertext depend only on the LSB of each of the 16 words
of the plaintext. Second, note that this dependency is in fact affine.
(The only non-linearity in the above is the carry bits, but there are no
carry bits coming into the LSB.) Consequently, given a few dozen known
texts, we can find this affine transformation, using Gaussian elimination.
Knowing this affine transformation almost gives away the low 4 bits of
each of the key words, because it tells us how the words are permuted.
In other words, each key word above induces a swap (i, key[i]&0xf),
and the composition of these 16 swaps is known. This already gives us
a lot of information on the key material, and moreover it allows us to
read the LSB's of any subsequent encrypted traffic.
At this point, any of a number of strategies are available to finish off
the attack. For instance, if we know the low 4 bits of each key word
(64 bits in total), we can break the cipher trivially, since we know
where all the swaps go. But knowing the permutation above gives a lot of
information on those 64 key bits (it gives about 44 bits of information,
in particular), so we may be able to just try all the possibilities
(heuristically, we expect to have to try only 2^20 possibilities).
That ought to be good enough to break it the rest of the way.
------------------------------
Date: Fri, 23 Jun 2000 01:54:15 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: small subgroups in Blum Blum Shub
=====BEGIN PGP SIGNED MESSAGE=====
David Hopwood wrote:
> Tim Tyler wrote:
> > lordcow77 <[EMAIL PROTECTED]> wrote:
> >
> > : Essentially, the existence of exploitable cycles in BBS would
> > : neccesarily lead to an efficient algorithm for decomposing RSA
> > : moduli into primes. As such, if you believe that the factoring
> > : of numbers in that range is a difficult problem, you need not
> > : loose sleep over the miniscule probability that you will land in
> > : a short cycle. [...]
> >
> > It's not a simply a case of losing sleep - it's a case of knowing
> > whether your system is secure.
> >
> > Short cycles are weak and insecure - no matter what the probability of
> > their arising is.
>
> AFAICS from Theorem 4 of the BBS paper, lordcow77's argument is correct.
> That theorem shows that breaking the BBS generator is as hard as factoring
> N = pq even if the only constraints are that p and q are congruent to
> 3 mod 4 and x_0 is a quadratic residue, regardless of what the cycle
> length is.
Correction: it shows that breaking the BBS generator is as hard as breaking
the quadratic residuosity assumption (as defined in the BBS paper, i.e.
for all but a negligable fraction of moduli N = pq and seeds), even if
the only constraints are that p and q are primes congruent to 3 mod 4
and x_0 is a randomly selected quadratic residue.
The QRP has not been proven to be equivalent to the integer factorisation
problem.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOVF0uzkCAxeYt5gVAQE8Rgf/dbpPnQS9Agll7bFqtV2kx7J2Bqn7+eq0
GlxLm7wA/bBnXfYn8yrEC2JOphyT7IdFa7iuxroWZ9EgoYUg6jT5l7krMI6ypGCp
qHJnkpDH58fGTvdfy8KPPnQH3CRVSA8NfW/4r8yRAgbZaYMm/q2V73Rre6abEblY
ZLKwxo6xlewYd5/2Oyy7iuSwXU98qxrYNTOzVhvZomV5L2uongEBzpqesiAyiws5
pWIsQRCZorXar6Myk5YWJyUv6UVNNIPNX3MK/Wn8l74Et2Fp2wNJub60SSyyTn1H
YdVL4xBlm322Vc8UOElLht+5tiX+qdpHbyHOWuE80jiY61eBC1PyrQ==
=8iPa
=====END PGP SIGNATURE=====
------------------------------
Date: Fri, 23 Jun 2000 02:33:00 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: MD5 Expansion
=====BEGIN PGP SIGNED MESSAGE=====
Simon Johnson wrote:
>
> A much better way is to divide the message in two. Then hash
> each part individually and contatenate each hash.
>
> a = 1/2 of M
> b = other 1/2 of M
> Hash output = H(a) & H(B)
No, this is a disastrous idea, because one half of the message can be
held constant in a collision attack. That means it is only as collision-
resistant as H.
The modification with bytes of the message interleaved also doesn't work,
because odd or even-numbered bytes can still be held constant.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOVK+LDkCAxeYt5gVAQEMNQf+JcWEElmM28R6upvkdxVRcGb5HrNDMiSt
5iXCHrjsSE3/AlVdRiUeflOD0y6WXrxKgfC92QGWYmN2cVgU0NO6Qs3LxT4UEwr8
YAafhcTJZMxO+sAOBt9ephlxoIQAvTDGUN5rsMAGUsDtF5XNN8rJx3tqKm8UkX3o
ZGo+WVpvS4KSrQvCaHmc41N79OOD3Jsvesf53mYmZ+Usxnnqqyqi2F4gDK1u/y38
bjEoiJeMFc/vNRT0MnKDCuS3xe/alitFarnPiYxQaAQXxDEm+XSZpnDOfmlwFlfe
L5BjTAIPW6NDr1bbNQZawjEl4dPqCPxH34gtK8FS0FpydEC67eS1VA==
=NSDK
=====END PGP SIGNATURE=====
------------------------------
Date: Fri, 23 Jun 2000 03:06:57 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: AES key lengths
=====BEGIN PGP SIGNED MESSAGE=====
Mark Wooding wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> > It is indeed strange that you have seen very few recent ciphers which
> > hav fixed-length key sizes. The most recent ciphers of significance
> > are certainly the AES candidates. How many of these allow you to vary
> > the key size from 128 by steps of, say, 8 all the way to 256?
DFC, FROG, RC6 and Twofish. (Also CRYPTON-1.0, which wasn't technically
an AES candidate.)
> > (Note we were discussing about 'slightly larger keys', not giant
> > jumps.)
>
> Off the top, RC6, Twofish, Serpent, and CAST256. I think (but don't
> quote me) that MARS and HPC also qualify here, and possibly other things
> like DFC and Frog. Rijndael's key can be increased in steps of 32 bits.
The Rijndael spec only gives numbers of rounds for the 'official' AES
key lengths.
Key length (bits)
Algorithm Min Max Multiple
CAST-256 128 256 32
CRYPTON-0.5 64 256 32
CRYPTON-1.0 0 256 8
DEAL 128 256 64
DFC 0 256 8
E2 128 256 64
FROG 40 1000 8
HPC 0 no limit 1
LOKI97 128 256 64
MAGENTA 128 256 64
SAFER+ 128 256 64
MARS (original) 32 1248 32
MARS (tweaked) 128 448 32
RC6 0 2040 8
Rijndael 128 256 64
Serpent 128 256 64
Twofish 8 256 8
(These values come from http://www.users.zetnet.co.uk/hopwood/crypto/scan/,
and were derived from the specification documents for each cipher. Only key
lengths for which the cipher is fully specified are included.)
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOVLGAzkCAxeYt5gVAQETnQgAnlMS9UCIFjjZiiq0bE5Sm6uBMwN5mV+y
tR4vPz++MSkvkbK5rte8OmycV4p2dTm6u2Wr70nslZpOIrbiyG/UoB8Mt4vz5KOF
vsFG5o1vH9h2LekxfwKpHFOImaGOxvAPUxco48exc3aRAKDDeZFcIxF3b8wiF2FS
matOKdOaeZb8yvUJ1J1zJS8GuU2cq9jaCrUFaXvSuQ2o8EzXyb0Lz0dcsi3KnygP
azhox/nC5F2HJqa/n3rd/dz94J4ie+OiKSa4zDTzHbtNmVAR5dYEx/Z4e0WyJXTJ
Uwu28jp/cxOu6C0sXpxTEfzm56p6AhJJsXEFKomoMuE6rx6lYpC0nw==
=xZhd
=====END PGP SIGNATURE=====
------------------------------
Date: Fri, 23 Jun 2000 03:16:41 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Variability of chaining modes of block ciphers
=====BEGIN PGP SIGNED MESSAGE=====
Mok-Kong Shen wrote:
[re: varying block cipher modes on a per-message basis]
> I was not recommending any specific way of choosing among these
> 8 varaints (maybe plus some others). My point is that there are
> a number of varaints to be considered. If one determines that there
> are more than one variants that are appropriate for the application,
> then one can advantageously exploit the variability of using these
> variants.
No, not really. It makes the system more difficult to analyse, and has
no significant compensating advantages. If you want to argue otherwise,
respond specifically to the technical points I made in my previous post
(that some data will be encrypted using the weakest mode, and that under
some attack models the mode can be determined easily), rather than
handwaving.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOVLIQDkCAxeYt5gVAQELGQf/dH0bdl2avc4YKQ7NmknOFav42zGNclp+
XdrOSCc7VxIs0RKw4pP6Xx8CBch726aJREXSB1ABllUqU1N4T/xxAgXpzJs037KX
5ClVICI2FFuwQDp3bvtokO2QpzY01/hrs6jqvqN90Wj9eyOph8yBhtAVVeswr1f1
msfZLeE6QW2qpMSbttZFFFkcUZV/kK9Oe2TpFnblispFqIap11wIpZPC+W7AWsMo
kyX90X0+kEsR/u8Q/DGAHnGmkF+SJ+ZdvfWiyy0YKcPvfVhMFwtIZ+lg57MGFJ+a
Z156k9L6DbOnyu03WCGPf+tn4PZmqB9okRwVQcla0hSLgWn3N9sQpA==
=Risw
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: aus.students,aus.students.overseas,rmit.cs.general
Subject: Scholarship available to study Information Security at RMIT University
Date: Fri, 23 Jun 2000 05:34:06 GMT
If you are an international student applying for midyear entry (Semester
2 starts on 17 July) into the Master of Applied Science in Information
Security, you will be considered for a strategic scholarship.
If you are an Australian resident, the course is much cheaper!
See the details at
http://www.ma.rmit.edu.au/kepler/pgrad/InfoSec.html
Serdar Boztas
Course Coordinator
Information Security
RMIT University
CURRENT E-MAIL: [EMAIL PROTECTED] (Mail server at regular
e-mail is down).
International Students: E-mail [EMAIL PROTECTED] to for application
form.
Australian Students: E-mail [EMAIL PROTECTED] for application
form.
--
sevgilimin hayali dile geldi aynanin uzerinde/ "o yok, ben varim" dedi
bana
gunun birinde/vurdum dustu parcalandi ayna kayboldu hayal/ ve lakin
cok sukur duruyor sevgilimyerliyerinde Nazim Hikmet (1905-1963)
/\/\/\/\/\/\/ Serdar Boztas \/\/\/\/ [EMAIL PROTECTED] \/\/\/\/\/\/\/
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
