Cryptography-Digest Digest #283, Volume #13 Wed, 6 Dec 00 14:13:01 EST
Contents:
Re: DES and Salt ([EMAIL PROTECTED])
Re: Simulataneous encryption and authentification (was IBM's new (John Myre)
Re: Idea for ciphering? (correction w/ addition) (John Myre)
Re: Idea for ciphering? (Mok-Kong Shen)
Re: Possibly-new attack on D-H? ([EMAIL PROTECTED])
Re: Idea for ciphering? (Mok-Kong Shen)
Re: [Question] Generation of random keys ("Tony T. Warnock")
Re: weten we die PIN? ([EMAIL PROTECTED])
Re: File Deleter/Nuker ? (John Hairell)
Re: ---- Are AES algorithms export restricted? (CiPHER)
Re: DES and Salt ("Mike The Man")
Re: Smart Card vs 1.44 Disk ("Paul Pires")
Re: Smart Card vs 1.44 Disk ("Paul Pires")
Re: ---- Are AES algorithms export restricted? (Richard Heathfield)
Re: Possibly-new attack on D-H? ("Scott Fluhrer")
Re: Are there collisions in DES? (Quisquater)
Re: Are there collisions in DES? (Quisquater)
Re: Possibly-new attack on D-H? ("Michael Scott")
Re: wrapper code (Rex Stewart)
Re: [Question] Generation of random keys (Steve Portly)
Re: Why Galois Fields in Cryptography? (Mike Rosing)
Re: Journal of Craptology (Mike Rosing)
Re: Simulataneous encryption and authentification (was IBM's new algorithm)
(Francois Grieu)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DES and Salt
Date: Wed, 06 Dec 2000 16:02:24 GMT
In article <TNnX5.622$[EMAIL PROTECTED]>,
"Mike The Man" <[EMAIL PROTECTED]> wrote:
> Thanks, that's another step forward for me.
>
> I'm sorry to say it's still not working.
> Regarding the salt, yes it's implemented in the expansion function,
I've
>
...
Search for "crypt3.c" on google, I found this link where the author
claims his version works:
http://www.cs.ucsb.edu/~mdipper/crypt3.html
If it still doesn't match your version then maybe your unix is not
standard.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Simulataneous encryption and authentification (was IBM's new
Date: Wed, 06 Dec 2000 09:21:12 -0700
David Wagner wrote:
<snip>
> The adversary can get the encryption of any block B he likes with
> a single chosen-message query simply by picking a message M[0..n-1]
> so that the xor of the message equals B. Since the ability to encrypt
> is the only thing needed to create valid ciphertexts, this means that
> the adversary can compute the encryption of any target message he likes.
<snip>
I am definitely not following this. What I read the above as
saying is "if the adversary can choose messages to encrypt,
he can choose what blocks to encrypt". That sounds like a
tautology to me.
What am I missing?
JM
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Idea for ciphering? (correction w/ addition)
Date: Wed, 06 Dec 2000 09:13:40 -0700
Jorgen Hedlund wrote:
>
> (correction with some additions)
>
> I was trying to sleep last night when I got to think of this
> cipher algorithm. Well, not exactly an algorithm, more like
> an idea for one.
>
> Imagine a statemachine, and its state transition table (STT).
<snip>
Actually, that would be a good abstract description of any
stream cipher.
Part of the security would rest in the size of the state: if
it is too small, the cryptanalyst could simply do a brute-force
guess of the (initial) state. On the other hand, a large state
means a really large STT. So any practical system uses
computation for (at least part of) the "next state" function.
It might be instructional to consider a few stream ciphers
and relate them to the state machine model. PRNG ciphers
like RC4 don't use the plaintext or ciphertext to affect the
state, so in the state machine model every transition is
independant of the input. But a general "stream cipher" is
not limited this way, and can use plaintext or ciphertext
feedback if desired.
JM
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Idea for ciphering?
Date: Wed, 06 Dec 2000 17:26:00 +0100
Jorgen Hedlund wrote:
>
> Imagine a statemachine, and its state transition table (STT).
> For example if the alphabet consists of {a,b,c,d, EOS} and the
> machine has 4 states, this could be one STT:
>
> chr -> a b c d
> --------+----------------
> state 1| 2 3 4 1
> 2| 4 3 2 1
> 3| 1 3 2 4
> 4| 4 2 3 1
>
> Then imagine that each state do some transformation of the
> character. Let's denote this transformation Tn() for
> state n.
>
> For instance if the transformations are simply some kind
> of substitution, then their keys could be like this:
>
> F1() key = abcd -> EwGy
> F2() key = abcd -> %thE
> F3() key = abcd -> !ikz
> F4() key = abcd -> &hus
>
> Then using this presettings, a string "bddacda" would be
> encoded as: (n+ = next state)
>
> Start state = 1
>
> F1(b) = w, n+ = 3
> F3(d) = z, n+ = 4
> F4(d) = s, n+ = 1
> F1(a) = E, n+ = 2
> F2(c) = h, n+ = 2
> F2(d) = E, n+ = 1
> F1(a) = E, n+ = 2
> <EOS>
>
> result "wzsEhEE"
>
> The public key are the above STT, while a private key would
> consist of a reversed STT.
>
> Without the reversed STT, there would be really difficult to
> decrypt. Right?
>
> The Fn()'s should probably be something else than standard
> substitution, but I used it as an example.
>
> And, ofcourse, the STT would be a 256*<no of states> grid,
> if we use bytes.
>
> Well, any comments?
>
> Any mathematical stuff that might be interesting? (I like 'em
> but can't produce 'em)
What do you mean by a reversed STT? If I don't err, the
receiver, starting with the start state, can do the
decryption with the STT as given. The same can hence be
done by the opponent. If follows that you have to keep
the STT secret. You employ the state, which is influenced
by the input plaintext, to control the processing. There
are some schemes that utilize this general idea to certain
extent, though not in the explizit form of employing a STT,
as far as I am aware. (But others may correct me.)
M. K. Shen
=============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Possibly-new attack on D-H?
Date: Wed, 06 Dec 2000 16:16:25 GMT
In article <[EMAIL PROTECTED]>,
Paul Rubin <[EMAIL PROTECTED]> wrote:
> Tom St Denis <[EMAIL PROTECTED]> writes:
> > I believe in PGP new primes are chosen for each new DH/DSS key.
>
> No there's a table of fixed Sophie Germain primes of various lengths.
> They are generated according to an algorithm given in a comment in
> the code. It also says how long it took to generate each one. For
> the 1024 bit one I think it was on the order of an hour.
>
You can generate safe primes quite easily. For instance, using
MIRACL and C++ ...
#include <iostream.h>
#include <big.h>
Miracl mip(1000);
int main()
{
long nbits=1024;
(&mip)->IOBASE=16;
Big random_number("1231231223ABE267F4765743EA473467"
"98890232637433CCD4547363B5752210"
"1436123AFC4125624532432532430039"
"9697567BED6384560AA845732F235754");
Big base=2;
base=pow(base,nbits-1);
base+=random_number;
Big p=nextsafeprime(0,0,base);
(&mip)->IOBASE=10;
cout << "SAFE PSEUDO-PRIME: (decimal) " << p << endl;
(&mip)->IOBASE=16;
cout << "SAFE PSEUDO-PRIME: (hex ) " << p << endl;
(&mip)->IOBASE=10;
cout << "PSEUDO-PRIME: ((p-1)/2 decimal) " << (p-1)/2 << endl;
(&mip)->IOBASE=16;
cout << "PSEUDO-PRIME: ((p-1)/2 hex ) " << (p-1)/2 << endl;
return 0;
}
This takes 1min 30secs on my laptop, and proving
primality using Titanix took 1min 32secs for p, and
1min 31secs for (p-1)/2.
Of course if you want to choose a generator, you are going to
to check that it is a primitive root of p. Any suggestions?
In SNAKE I use large generators g > SQRT(p) and find safe primes
where p=g+x^2. This takes much longer, but still finds several
per hour.
ttfn
PG.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Idea for ciphering?
Date: Wed, 06 Dec 2000 17:47:18 +0100
Sorry, I erred. Since the F's are secret, the STT can be
public.
M. K. Shen
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: [Question] Generation of random keys
Date: Wed, 06 Dec 2000 09:49:23 -0700
Reply-To: [EMAIL PROTECTED]
Steve Portly wrote:
-A simple test which a surprising number of PRNG's fail is to run the PRNG
-in isolation. If the PRNG is used in a computing environment, get a
-stripped down copy of the OS and PRNG loaded on a CD or floppy disk with
-no support files. Boot the computer from the auxiliary drive and
-immediately call the PRNG. Chances are good that you will get the same
-output each time you reboot. The PRNG's supplied with many operating
-systems fail this simple test.
This behavior is not necessarily a failure. When debugging a code, one needs
reproducibility. It depends on the use to which the PRNG is put.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.cracks.nl,alt.nl.telebankieren,nl.comp.crypt,nl.financieel.bankieren,nl.juridisch
Subject: Re: weten we die PIN?
Date: 6 Dec 2000 17:01:59 -0000
In nl.juridisch David Dylan <[EMAIL PROTECTED]> wrote:
> Hoe vaak je een verkeerde pincode intikt.
zover ik weet de bank zelf. als je twee keer verkeerd intikt en op een
willekeurige andere plaats weer goed intikt, dan is de zaak weer
gereset.
--
Grobbebol's Home | Don't give in to spammers. -o)
http://www.xs4all.nl/~bengel | Use your real e-mail address /\
Linux 2.2.16 SMP 466MHz / 256 MB | on Usenet. _\_v
------------------------------
From: [EMAIL PROTECTED] (John Hairell)
Subject: Re: File Deleter/Nuker ?
Date: Wed, 06 Dec 2000 17:21:21 GMT
On Sat, 02 Dec 2000 20:15:19 GMT, Tom St Denis <[EMAIL PROTECTED]>
wrote:
[stuff snipped]
>Most of the time hard disks are so dense that writing over the data
>once is often enough. "Multi-pass" file wipers are just plain paranoia
>food. On floppy disks your best bet is to burn them since they are
>cheap. But because hard disks store information so densely the
>probability of left over data is next to nill.
The US government requires that hard drives containing classified data
be overwritten at least seven times prior to destruction. It might be
surmised that the number seven wasn't just picked at random. Perhaps
they know something you don't.
Also, certain investigative organizations of the US government possess
(and use) hardware that reads wiped drives. Perhaps they know
something you don't.
John Hairell ([EMAIL PROTECTED])
------------------------------
From: CiPHER <[EMAIL PROTECTED]>
Subject: Re: ---- Are AES algorithms export restricted?
Date: Wed, 06 Dec 2000 17:24:16 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Since monitoring can be performed by a foreign country
> (see Echelon) and we know how many are those powers
> that can do that, from (1), the answer to your question
> is clearly the null set.
>
> M. K. Shen
Which was along the lines of what I was about to post...
...plus just because a country doesn't have legislation in place to
allow them to arhcive and analyse your communications doesn't mean they
aren't doing it.
As for someone mentioning Ireland's beaches... well, they're supposed to
be nice, but they look rather boring to me. *shrugs* It's too freezin'
anyway...
--
[ marcus ] [ http://www.cybergoth.cjb.net ]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Mike The Man" <[EMAIL PROTECTED]>
Subject: Re: DES and Salt
Date: Wed, 6 Dec 2000 18:40:19 +0100
Thanks!
[EMAIL PROTECTED] skrev i meddelandet <90lnub$cpr$[EMAIL PROTECTED]>...
>In article <TNnX5.622$[EMAIL PROTECTED]>,
> "Mike The Man" <[EMAIL PROTECTED]> wrote:
>> Thanks, that's another step forward for me.
>>
>> I'm sorry to say it's still not working.
>> Regarding the salt, yes it's implemented in the expansion function,
>I've
>>
>...
>
>Search for "crypt3.c" on google, I found this link where the author
>claims his version works:
>http://www.cs.ucsb.edu/~mdipper/crypt3.html
>If it still doesn't match your version then maybe your unix is not
>standard.
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Smart Card vs 1.44 Disk
Date: Wed, 6 Dec 2000 09:50:59 -0800
John Myre <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> JustBrowsing wrote:
> <snip>
> > Does giving the medium a "mind of its own" really make a difference.
> <snip>
>
> I'd like to hear more responses on this, too. Smart cards
> are greatly popular in Europe, but not in the United States.
> Why this is I do not know, unless it be inertia.
I think the reason that Smart cards haven't taken off in the US
is due to the marketing. No one is telling the user why they
should be excited about this and what it does for them.
By user, I mean the public at large. When I talk about
what smart cards could do for folks (one-on-one) they are
ammazed. They say "So that's what it is, that's neat."
This Dumbing down, "It's good cause it's high tech"
approach is biting folks in the ass. The best marketing
is pull marketing. If you want to sell to Visa or MC,
sell their customers and thet the demand pull it in.
> There is certainly one good reason for smart cards: the secrets
> can stay there, and you don't have to worry about the problem
> of insecure PC's. That is, for any crypto, there has to be
> a place to compute with the most sensitive secrets (the keys).
> That place must not leak the secrets; and a sensible way of
> attaining that goal is to make it simple, so that we have a
> chance of getting it right. With a "dumb" medium like a disk,
> some *other* computer must do the computing, and thus learn the
> secret keys; and it might be that said computer can't be trusted.
The problem is (to me) that the implementors don't have a clear
idea of why they should do it other than the fact that it is "high tech"
An idea must penetrate a minimum volume of the corporate mass
to generate a "we got to do this" reflex. Corporations are not
sentient. Their behavior is simple stimulus response.
One big problem is oversell. Just show folks how fraud exposure
can be limited to a set and controllable level. It does not have to
be fraud immune. Saying things like that sets off alarms with the
risk adverse.
Paul
>
> That, at least, is the idea. The actual implementation of
> current smart cards could best be described as "not perfect."
>
> JM
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Smart Card vs 1.44 Disk
Date: Wed, 6 Dec 2000 09:52:48 -0800
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:90k0pr$2l7$[EMAIL PROTECTED]...
> In article <90jrg4$ic9$[EMAIL PROTECTED]>,
> "JustBrowsing" <[EMAIL PROTECTED]> wrote:
> > Smart Card vs 1.44 Disk
> >
> > This is probably a really dumb question but once I get past all the
> smart
> > card marketing, I cant see the advantages of a smart card over a 1.44
> disk
> > using good crypto techniques.
> >
> > I keep coming to this conclusion, once data has been securely locked
> up,
> > does it matter what the medium is?
> > Does giving the medium a "mind of its own" really make a difference.
> >
> > Just dont get it!
> > For the sake of argument please assume all mediums are equal. For
> example,
> > yes, 1.44 disks get messed up easily, mag stripes cant hold a huge
> amount of
> > info etc.
> > Get past that and tell me why smart card as a medium can do something
> a 1.44
> > disk and PC with reader cant?
> >
> > I'm thinking about setting up a travel agency voucher system... why
> must I
> > buy expensive smart cards?
>
> "Anonymous" pointed out the secrecy of smart cards. Also you can carry
> a smart card around and it can do the work for you such as decrypting
> messages or signing something. You don't need a host to run the task
> for you.
Sorry for the "Anonymous ". I'm trying to find a decent usenet server.
Paul
>
> Some smart cards (or tokens) can be used for remote logins if they are
> equipped with an LCD display.
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
Date: Wed, 06 Dec 2000 18:09:23 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: ---- Are AES algorithms export restricted?
CiPHER wrote:
>
> In article <[EMAIL PROTECTED]>,
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> > Since monitoring can be performed by a foreign country
> > (see Echelon) and we know how many are those powers
> > that can do that, from (1), the answer to your question
> > is clearly the null set.
> >
> > M. K. Shen
>
> Which was along the lines of what I was about to post...
>
> ...plus just because a country doesn't have legislation in place to
> allow them to arhcive and analyse your communications doesn't mean they
> aren't doing it.
That doesn't matter, as far as I'm concerned, because I'm quite happy to
pit my meagre wits against a Government's supercomputers (if it ever
came to that). What annoys me about the UK is that they don't have to
even turn their supercomputers on - they can just knock on (or down) my
door and demand the key, and it'll stand up in court.
>
> As for someone mentioning Ireland's beaches... well, they're supposed to
> be nice, but they look rather boring to me. *shrugs* It's too freezin'
> anyway...
It can't be any worse than Northamptonshire. Ireland looks like a very
attractive proposition. Whoever suggested it - thank you very much.
Presumably, some enterprising Irishman has a Website offering amazingly
secure crypto products to anyone in the world, at very reasonable
prices. :-) If not, why not? And if so, then the American restrictions
seem particularly pointless.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Possibly-new attack on D-H?
Date: Wed, 6 Dec 2000 10:12:18 -0800
<[EMAIL PROTECTED]> wrote in message
news:90looh$dff$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>,
> Paul Rubin <[EMAIL PROTECTED]> wrote:
> > Tom St Denis <[EMAIL PROTECTED]> writes:
> > > I believe in PGP new primes are chosen for each new DH/DSS key.
> >
> > No there's a table of fixed Sophie Germain primes of various lengths.
> > They are generated according to an algorithm given in a comment in
> > the code. It also says how long it took to generate each one. For
> > the 1024 bit one I think it was on the order of an hour.
> >
>
> You can generate safe primes quite easily. For instance, using
> MIRACL and C++ ...
[snip]
Does this program produce Sophie Germain primes? (I don't know Micacl's
specification of "nextsafeprime")
>
> Of course if you want to choose a generator, you are going to
> to check that it is a primitive root of p. Any suggestions?
If p and (p-1)/2 are prime (which is what the OP meant by Sophie Germain
prime), then it's easy: a number g is a primitive root of p iff both
following two equations hold:
g != -1 mod p
g**((p-1)/2) == -1 mod p
Half of the numbers in the range (1, p-1) are primitive roots for SG primes,
so trying g's at random is efficient.
Of course, if you are doing DH, you may want a quadratic residue instead.
In that case, it's even easier: 2 is always a quadratic residue of p (again,
if p and (p-1)/2 are prime).
BTW: if you are doing DSS, you can't use a SG prime, you need a prime p
where (p-1)/2 has a large proper factor
--
poncho
------------------------------
From: Quisquater <[EMAIL PROTECTED]>
Subject: Re: Are there collisions in DES?
Date: Wed, 06 Dec 2000 19:52:47 +0100
Simon Johnson wrote:
>
> In article <903km5$125q$[EMAIL PROTECTED]>,
> "David C. Barber" <[EMAIL PROTECTED]> wrote:
> > Are there collisions in DES? What I mean by that is:
> >
> > 1: Can 2 different keys with the same source give the same
> > encrypted
> > result?
>
> No.
Sorry. The answer is: yes, it is possible. For DES,
the first public collision was found January 13, 1989,
see and, please, read our papers:
J.-J. Quisquater and J.-P. Delescaille: How easy is collision search?
Application to DES (Extended summary). In J.-J. Quisquater and J. Vandewalle,
eds, Advances in Cryptology -- Eurocrypt '89, vol. 434 of Lectures Notes in
Computer Science, Springer-Verlag, pp. 429-434, 1990.
J.-J. Quisquater and J.-P. Delescaille: How easy is collision search. New
results and application to DES. In G. Brassard, ed., Advances in Cryptology
-- Crypto '89, vol. 435 of Lectures Notes in Computer Science, Springer-Verlag,
pp. 408-413, 1990.
In fact, they are more results presented during some rump sessions of CRYPTO.
I hope to put it on my web pages some day (I've more than 100 examples of
such cases, called collisions).
------------------------------
From: Quisquater <[EMAIL PROTECTED]>
Subject: Re: Are there collisions in DES?
Date: Wed, 06 Dec 2000 19:53:40 +0100
Simon Johnson wrote:
>
> In article <903km5$125q$[EMAIL PROTECTED]>,
> "David C. Barber" <[EMAIL PROTECTED]> wrote:
> > Are there collisions in DES? What I mean by that is:
> >
> > 1: Can 2 different keys with the same source give the same
> > encrypted
> > result?
>
> No.
Sorry. How do you know? The answer is: yes, it is possible. For DES,
the first public collision was found January 13, 1989,
see and, please, read our papers:
J.-J. Quisquater and J.-P. Delescaille: How easy is collision search?
Application to DES (Extended summary). In J.-J. Quisquater and J. Vandewalle,
eds, Advances in Cryptology -- Eurocrypt '89, vol. 434 of Lectures Notes in
Computer Science, Springer-Verlag, pp. 429-434, 1990.
J.-J. Quisquater and J.-P. Delescaille: How easy is collision search. New
results and application to DES. In G. Brassard, ed., Advances in Cryptology
-- Crypto '89, vol. 435 of Lectures Notes in Computer Science, Springer-Verlag,
pp. 408-413, 1990.
In fact, they are more results presented during some rump sessions of CRYPTO.
I hope to put it on my web pages some day (I've more than 100 examples of
such cases, called collisions).
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: Possibly-new attack on D-H?
Date: Wed, 6 Dec 2000 18:37:09 -0000
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
news:90lvo8$p2n$[EMAIL PROTECTED]...
> > .....
> In that case, it's even easier: 2 is always a quadratic residue of p
(again,
> if p and (p-1)/2 are prime).
>
No its not. It is if p=7 mod 8, but not if its 3 mod 8. Obviously such a
prime p =3 mod 4 - if it were 1 mod 4 then (p-1)/2 would be even and hence
not a prime. However 3 is always a quadratic residue, as (of course) is 4 or
any x^2.
Mike Scott
> BTW: if you are doing DSS, you can't use a SG prime, you need a prime p
> where (p-1)/2 has a large proper factor
>
> --
> poncho
>
------------------------------
From: Rex Stewart <[EMAIL PROTECTED]>
Subject: Re: wrapper code
Date: Wed, 06 Dec 2000 18:39:43 GMT
I think you miss understood his question, which should probably
have been asked in one of the computer language newsgroups.
I think he is looking for a snippet of C or Pascal or some
other language that would:
read 8 bytes from a string
cast them into two long unsigned integers
--
Rex Stewart
PGP Print 9526288F3D0C292D 783D3AB640C2416A
In article <90k182$323$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <90jbh1$ilf$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Steve Blinkhorn) wrote:
> > 64-bit block ciphers all seemed to be coded to take pointers to two
> long
> > integers as arguments. Simple question to avoid reinventing wheel:
> > is there a bit of standard wrapper code somewhere to feed a
> > random-length byte string to such a cipher (blowfish is what I have
> > in mind)?
>
> Depends on what chaining mode you plan on using. I would suggest
> either CBC or a counter-feedback-mode (i.e encrypt a counter and xor).
>
> Tom
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Subject: Re: [Question] Generation of random keys
Date: Wed, 06 Dec 2000 13:51:27 -0500
"Tony T. Warnock" wrote:
> Steve Portly wrote:
>
> -A simple test which a surprising number of PRNG's fail is to run the PRNG
> -in isolation. If the PRNG is used in a computing environment, get a
> -stripped down copy of the OS and PRNG loaded on a CD or floppy disk with
> -no support files. Boot the computer from the auxiliary drive and
> -immediately call the PRNG. Chances are good that you will get the same
> -output each time you reboot. The PRNG's supplied with many operating
> -systems fail this simple test.
>
> This behavior is not necessarily a failure. When debugging a code, one needs
> reproducibility. It depends on the use to which the PRNG is put.
The only possible failure here is if the PRNG is claimed to be a "true random"
source. I am cautious in using the term RNG since perhaps even atomic decay
relies on some prior state that could be measured.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Why Galois Fields in Cryptography?
Date: Wed, 06 Dec 2000 12:56:45 -0600
Tom St Denis wrote:
>
> Hmm yeah, GF math is pretty cool and they certainly don't teach it in
> school.
>
> (BTW Mike: I never did fix my inversion in my "gfmath.c" listing... oh
> well)
don't worry about it. Life is too short and there's too many things to
learn. When you need again, then you fix it :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Journal of Craptology
Date: Wed, 06 Dec 2000 12:53:56 -0600
Mok-Kong Shen wrote:
> Sorry for my ignorance. What is 'forward security'?
It means that if an attacker can crack your key for this message, he
can't use anything he's learned to crack the key to the next message.
It also applies backwards, but I don't really understand why that's
called "forward". The main point is that each key requires the same
amount of effort to find.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Simulataneous encryption and authentification (was IBM's new algorithm)
Date: Wed, 06 Dec 2000 20:03:34 +0100
John Myre <[EMAIL PROTECTED]> wrote:
> David Wagner wrote:
> <snip>
>> The adversary can get the encryption of any block B he likes with
>> a single chosen-message query simply by picking a message M[0..n-1]
>> so that the xor of the message equals B. Since the ability to
>> encrypt is the only thing needed to create valid ciphertexts, this
>> means that the adversary can compute the encryption of any target
>> message he likes.
> <snip>
>
> I am definitely not following this. What I read the above as
> saying is "if the adversary can choose messages to encrypt,
> he can choose what blocks to encrypt". That sounds like a
> tautology to me.
For an encrypt algorithm, and even more in our case of an
encrypt-and-authenticate algorithm, it could be a desirable property
that an adversary can not build a matching plaintext message and
ciphertext message other than by submitting it to the legitimate
sender. The rationale is that maybe the sender accepts to encrypt
messages, except if they have some property.
David Wagner's attack does just this: by submitting a series of
short, meaningless messages to the sender, an attacker is able to
forge a ciphertext that will be accepted by the receiver, when
deciphered by the receiver will give any plaintext the attacker
has selected.
Francois Grieu
------------------------------
** 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
******************************
