Cryptography-Digest Digest #954, Volume #10 Sat, 22 Jan 00 13:13:00 EST
Contents:
Re: simplistic oneway hash ([EMAIL PROTECTED])
Re: NIST, AES at RSA conference (John Savard)
Re: Combination of stream and block encryption techniques (John Savard)
Re: MIRDEK: more fun with playing cards. (Paul Crowley)
Re: MIRDEK: more fun with playing cards. (Paul Crowley)
Re: MIRDEK: more fun with playing cards. (Paul Crowley)
Re: Calculating A^-1 Mod P (Kent Briggs)
Re: Intel 810 chipset Random Number Generator (Herman Rubin)
from DEAL to ZEAL (Francois Grieu)
Re: Java's RSA implimentation (Paul Schlyter)
Re: Calculating A^-1 Mod P (Paul Schlyter)
Re: McDonald's claims Nobel peace fries [off-topic] (Paul Schlyter)
Re: Wagner et Al. (Lincoln Yeoh)
Does RSA use real prime ? ("Hank")
Re: MIRDEK: more fun with playing cards. ("r.e.s.")
ADFGVX Construction (UBCHI2)
Re: Combination of stream and block encryption techniques (Mok-Kong Shen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: simplistic oneway hash
Date: 22 Jan 2000 12:12:01 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] () wrote:
> I have what is probably a rather unusual request. I need a very simple
> to code and understand one-way hash. I don't care a great deal as to
> whether it is truly secure at all, as long as it can be implemented
> in no more than a couple dozen lines of code in Fortran 90.
Have a look at WAKE's hash function - the 8 table version. It's on my
site. The code is for 32-bit machines and there may be a problem with
the way Fortran handles integer overflows (they will have to be
suppressed).
Keith
http://www.cix.co.uk/~klockstone
------------------------
'Unwise a grave for Arthur'
-- The Black Book of Carmarthen
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST, AES at RSA conference
Date: Sat, 22 Jan 2000 12:40:20 GMT
On Sat, 22 Jan 2000 03:15:50 GMT, Hammer <[EMAIL PROTECTED]> wrote,
in part:
>With all due respect, and just for clarification, I'm assuming you are
>not saying "they must all be good because they were done by the top
>level folks?"? I mean that question most humbly, I just want to
>clearly understand your point.
I don't quite mean that; you are right that such an assumption is a
fallacy. Anyone can make a mistake.
But while "must be good" is wrong, "is likely to be good" and "can
possibly be good" are true. We can reasonably expect that these
submissions, if they have flaws, have flaws that at least are harder
to find. If a serious flaw, of a type already known, was found in a
submission from someone who should have known better, that would come
as a _surprise_, and so the absence of such surprises is _not_
surprising.
So I'm not making a claim about what must be, only what we may expect.
Although there is no way to prove that there is not some devastating
attack on any or all of the AES candidates that just hasn't been
discovered yet, it's unlikely that money could buy cryptanalysis of
them that would be significantly better than what they've recieved
already.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Combination of stream and block encryption techniques
Date: Sat, 22 Jan 2000 12:50:09 GMT
On Sat, 22 Jan 2000 09:24:32 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>Please kindly expain a bit. If key stream is not the fundamental
>component of a stream cipher, what is the fundamental component?
>Could we have a stream cipher without a key stream? (Terry Ritter
>did mention one, but very unfortunately he couldn't give any
>literature reference, excepting that he has sometime before heard
>someone saying something about that.)
Well, I'm not too sure about a "stream cipher without a key stream"
myself; I think it is pretty hard to design a stream cipher without
something we could at least _call_ a key stream.
But that a key stream might not be the only fundamental component, or
even the most important component, of a stream cipher is reasonable.
Terry Ritter's own Dynamic Substitution is an example of how something
else in a stream cipher can be important besides the key stream.
In DynSub, bytes of plaintext are replaced by looking them up in a
256-byte table containing a permutation of the values from 0 to 255.
Then, the byte in the table that was used is swapped with the byte in
the table indicated by the current keystream byte.
In such a cipher, the keystream certainly plays a role, but the table
is also responsible for an important part of the transformation to
which the plaintext is subjected.
A way in which a cipher could be said to have "no keystream" would be
if the keystream byte, rather than being generated from an internal
state in a PRNG, is a function of the previous ciphertext bytes. This
is similar to CFB mode of a block cipher. Since this has reasonable
error-propagation qualities, it is used in practice.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: 22 Jan 2000 10:15:44 -0000
CLSV <[EMAIL PROTECTED]> writes:
> > When you say "one time", you mean "once per message".
> No, I mean just once before encrypted communication starts.
Could you be more explicit about how you then go on to encrypt more
than one message?
I can think of one way, which is simply to start the new message with
the state where you left off the old message, but this requires that
the recipient either receive all of your messages (unlikely) or at
least know how long they all were (OK if your recipient is decrypting
with a computer).
However, the requirement that you carry this state around with you is
burdensome - with Mirdek, you can throw away your (sorted) pack of
cards at the border, buy a new pack in a new country, and start
encrypting again, all using only a memorised passphrase. There must
be ways to achieve this goal with an ARC4 variant.
> Why do you keep insisting that exchanging a 225 bit password is the
> same as exchanging a one time pad?
Because I'm guessing that a lot of messages will be fewer than 52
characters long, so you could ship a one-time-pad suitable for
encrypting them just as easily as you could ship one of your keys.
However if you do have a practical way to encrypt more than one
message then this objection won't hold.
> > Diceware to generate them, this will give you 77.5 bits of entropy
> >in your keyphrase - enough to keep even the best funded attackers off
> >your back for quite a while.
>
> I believe nowadays 80 bits is thought to be the bare minimum for
> secure communication.
80 bit passphrases are kind of hard to come by. If you want the
incredible convenience of passphrases, as well as freedom from the
risk of the key being found by physical search, you have to put up
with a little loss in key entropy. In practice raising the resources
to brute-force a 77.5-bit key is still out of anyone's reach today -
consider that the 64-bit RC5 cracking project is still going and
doesn't expect to finish for years.
> There are ways to communicate a 52 card password that don't draw
> suspicion. For example you could agree on using the last 52 unique
> reverse digrams from a specific article of the popular political
> journal "The Great Dictator".
What's the key entropy under these circumstances, though? I'm
guessing that many fewer than 2^80 such diagrams have ever been
published. Even including transformations, you'll have a hard time
getting much key entropy.
(Apologies if anything I write here sounds harsh, I've just been
dragged out of bed to let the TV aerial worker in. I'm enjoying this
thread a lot and grateful to all participants!)
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: 22 Jan 2000 11:29:51 -0000
"r.e.s." <[EMAIL PROTECTED]> writes:
> : The position of the pointers is part of the state of both pure ARC4
> : and ARC4-52, thus 52! * 52 * 52.
>
> I disagree. Your two extra factors of 52 have no counterpart in any
> free selection of values. The pointers are required to be initialized
> as x=y=0, and are thereafter completely determined by the algorithm's
> way of managing the evolution of the 52-element state-vector.
I guess it depends on your terminology. I'd say 52!*52*52 is the
state space, but that it can only start in a small part of that space.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: 22 Jan 2000 11:31:11 -0000
"r.e.s." <[EMAIL PROTECTED]> writes:
> Concerning the alleged bias in ARC4, imo it's so small as to be
> negligible in the context of hand ciphers.
I'm not sure why you use the word "alleged" here. Also we don't yet
know how large it would be for the variant you propose.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Re: Calculating A^-1 Mod P
Date: Sat, 22 Jan 2000 16:27:23 GMT
Michael Scott wrote:
> An alternative to the Euclidean algorithm, albeit a much slower alternative,
> is to calculate A^-1 mod P as A^(P-2) mod P (assuming that P is prime, which
> it is in this context.).
>
> Mike Scott
I think you meant to say Euler, not Euclid.
--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com
------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Subject: Re: Intel 810 chipset Random Number Generator
Date: 22 Jan 2000 11:24:11 -0500
In article <86au71$m0n$[EMAIL PROTECTED]>,
Michael Kagalenko <[EMAIL PROTECTED]> wrote:
>Guy Macon ([EMAIL PROTECTED]) wrote
>]In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul Koning) wrote:
................
> No. You are wrong. So long as you can reliably count the number of cycles
> of quartz crystal, you can use this to recover thermally random numbers.
> Temperature dependence may be indeed a proble, but it can be accounted
> for either by thermostabilising or by simply measuring it and feeding
> it into computational process.
Using the general idea of random, not only this, but everything
else, is random. But this does not mean that it will have the
independence properties needed for use as "random numbers".
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
From: [EMAIL PROTECTED] (Francois Grieu)
Subject: from DEAL to ZEAL
Date: Sat, 22 Jan 2000 17:35:09 +0100
Lately, I have been looking at DEAL, a former AES candidate
<http://www.ii.uib.no/~larsr/papers/deal.pdf>
Lars R Knudsen's idea of constructing a 128 bit block cipher from
a number of DES operations is attractive in Smart Cards, where DES
is often a hardware primitive.
But Stefan Lucks found attacks on DEAL in "On the security of the
128-bit block cipher DEAL," Fast Software Encryption Workshop,
March 24-26, 1999, pp 60-69.
<http://th.informatik.uni-mannheim.de/People/Lucks/papers.html>
I wonder if more security could be obtained using, instead of
DEAL's Feistel network, a structure like
------- -------
| Pl | | Pr |
------- -------
| |
/-------\ |
RK1 --> ENC | /---\
\-------/ /-->--|XOR|
| / \---/
*---->--/ |
| /-------\
/---\ | ENC <-- RK2
|XOR|--<--\ \-------/
\---/ \ |
| \--<----*
/-------\ |
RK3 --> ENC | /---\
\-------/ /-->--|XOR|
| / \---/
*---->--/ |
| /-------\
/---\ | ENC <-- RK4
|XOR|--<--\ \-------/
\---/ \ |
| \--<----*
/-------\ |
RK5 --> ENC | /---\
\-------/ /-->--|XOR|
| / \---/
*---->--/ |
| /-------\
| | ENC <-- RK6
| \-------/
| |
------- -------
| Pl | | Pr |
------- -------
This cipher, which I call 6 round ZEAL, is clearly reversible.
It uses as much DES operations as 6 round DEAL. I conjecture
it could be safer, because each round modifies both sides.
I fail to modify Stefan Lucks's attacks to ZEAL's structure.
Any comment, idea, of better pointer to literature on this
structure would be appreciated.
Francois Grieu
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Java's RSA implimentation
Date: 22 Jan 2000 16:07:10 +0100
In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
> Paul Schlyter <[EMAIL PROTECTED]> wrote:
>
> [BigInteger objects are "immutable". They can't be altered once created...]
>
> : What would happen if you instead of A=A+1 tried e.g. B=A+1; A=0; ???
>
> No juice. New A (=0) object created. Old A object still floats around
> the system like an unwanted turd.
OK -- what if you do:
BigInteger A[1000000], B[1000000];
for( i=0; i<1000000; i++ )
A[i] = <something>;
B = A;
Will the B = A discard the old B and create a new copy of B?
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Calculating A^-1 Mod P
Date: 22 Jan 2000 16:06:39 +0100
In article <86a6rp$[EMAIL PROTECTED]>,
HRook <[EMAIL PROTECTED]> wrote:
> So, how do you calculate A^-1 Mod P. I have a vague memory that the Extended
> Euclidian algorithm can do this, but I can't remember the details of this
> algorithm. Any help would be appreciated.
bigint inv( bigint a, bigint n )
{ /* Return x such that (a*x) mod n = 1 where 0 < a < n */
bigint g0=n, g1=a, g2;
bigint u0=1, u1=0, u2;
bigint v0=0, v1=1, v2;
bigint y;
while( g1 != 0 )
{ /* gi = ui*n + vi*a */
y = g0 / g1;
g2 = g0 - y*g1;
u2 = u0 - y*u1;
v2 = v0 - y*v1;
g0=g1, g1=g2;
u0=u1, u1=u2;
v0=v1, v1=v2;
}
if ( v0 >= 0 )
return v0;
else
return v0 + n;
/* or with unsigned arithmetic, simply:
return v0;
*/
}
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: McDonald's claims Nobel peace fries [off-topic]
Date: 22 Jan 2000 16:07:37 +0100
In article <[EMAIL PROTECTED]>,
Jerry Coffin <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] says...
>
> [ ... ]
>
>> Either we all die, or we quit fighting :-)
>
> That's not an either/or situation: if we all die, we'll surely quit
> fighting.
Not necessarily ... in old Norse mythology, you went to Valhalla
after death, where you continued fighting.... :-)))
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: Wagner et Al.
Date: Sat, 22 Jan 2000 17:08:04 GMT
Reply-To: [EMAIL PROTECTED]
On 20 Jan 2000 15:18:16 EST, [EMAIL PROTECTED] (Guy Macon) wrote:
>You have to actually take ownership to change the other rights.
>This is important because you can't give ownership. As a user,
>If an Administrator changes a file that you didn't give him
>rights to, you can tell because he now owns it, not you. In
>addition, there are lots of rights that even the Administrator
>and the OS don't have.
Hmm, and I thought the setowner utility allows you to give ownership...
Anyway there are lots of other ways for the Admin to 'give ownership', for
the Admin is admin <ominous laughter>.
Cheerio,
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: "Hank" <[EMAIL PROTECTED]>
Subject: Does RSA use real prime ?
Date: Sun, 23 Jan 2000 01:24:36 +0800
RSA related cryptosystem often refers to the lenghth of key. For example, a 1024 bit
PGP keypairs...
Since 1024 bit is not a small number, I am curious how programs like PGP can find a
big prime so rapidly.
I hear someone that these program does not use real prime. Instead, they use numbers
which are very possbile real primes on a
statistical base. Is this true ?
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Sat, 22 Jan 2000 09:38:27 -0800
"Paul Crowley" <[EMAIL PROTECTED]> wrote ...
: "r.e.s." <[EMAIL PROTECTED]> writes:
: > : "Paul Crowley" wrote:
: > : The position of the pointers is part of the state of both pure ARC4
: > : and ARC4-52, thus 52! * 52 * 52.
: >
: > I disagree. Your two extra factors of 52 have no counterpart in any
: > free selection of values. The pointers are required to be initialized
: > as x=y=0, and are thereafter completely determined by the algorithm's
: > way of managing the evolution of the 52-element state-vector.
:
: I guess it depends on your terminology. I'd say 52!*52*52 is the
: state space, but that it can only start in a small part of that space.
OK, but that seems misleading because one might be
led to suppose that there are log2(52!*52*52) bits of
entropy involved, when there are only log2(52!) bits.
(With the usual convention that the algorithm is
assumed to be known by the attacker.)
--
r.e.s. "Mistr Typo"
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (UBCHI2)
Subject: ADFGVX Construction
Date: 22 Jan 2000 17:49:44 GMT
One weakness in the implementation of playfair is that the user often places
the last letters of the alphabet in order at the bottom of the checkerboard.
For example, since the letter "Z" is infrequently used in a keyword, it usually
stays at the bottom right coordinate of the checkerboard, it is a giveaway.
How did the Germans determine the initial ADFGVX checkerboard. Was it based on
keywords that left some letters in their alphabetical order in the
checkerboard?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Combination of stream and block encryption techniques
Date: Sat, 22 Jan 2000 19:04:42 +0100
John Savard wrote:
>
> <[EMAIL PROTECTED]> wrote, in part:
>
> >Please kindly expain a bit. If key stream is not the fundamental
> >component of a stream cipher, what is the fundamental component?
> >Could we have a stream cipher without a key stream? (Terry Ritter
> >did mention one, but very unfortunately he couldn't give any
> >literature reference, excepting that he has sometime before heard
> >someone saying something about that.)
>
> Well, I'm not too sure about a "stream cipher without a key stream"
> myself; I think it is pretty hard to design a stream cipher without
> something we could at least _call_ a key stream.
>
> But that a key stream might not be the only fundamental component, or
> even the most important component, of a stream cipher is reasonable.
Yes, IF one introduces sophisticated components such that one could
(in some sense) say that these contribute MORE to the total security
of the algorithm than the security of the key stream alone could
contribute. In such a case the key stream becomes 'pushed away' from
its usual 'fundamental' position (i.e. it is no longer the 'star'.)
One simple example could be what I mentioned in a parallel follow-up
of this thread where the key stream is used to supply the (variable)
keys to different blocks of DES encryption. Here it appears reasonable
to consider that DES plays the major (more important) role in this
'combined' scheme.
> Terry Ritter's own Dynamic Substitution is an example of how something
> else in a stream cipher can be important besides the key stream.
>
> In DynSub, bytes of plaintext are replaced by looking them up in a
> 256-byte table containing a permutation of the values from 0 to 255.
>
> Then, the byte in the table that was used is swapped with the byte in
> the table indicated by the current keystream byte.
>
> In such a cipher, the keystream certainly plays a role, but the table
> is also responsible for an important part of the transformation to
> which the plaintext is subjected.
May I mention in this connection also my humble design WEAK3-EX
(see my web page), where a compound PRNG supplies pseudo-random
numbers (these constitute the 'key stream') to control in each
(user choosable variable number of) rounds the block encryption
operations (i.e. determining the permutations and substitutions
of bytes) in addition to supplying pseudo-random numbers to do
stream operations (i.e. providing the keys to perform a kind of
auto-key encryption on 32 bit units). There are also cyclic rotation
operations done on 32 bit units, with the amount of rotation
controlled by the pseudo-random numbers. Finally a hash value
in a round in each block determines the amount of the output of
the compound PRNG that are to be skipped before the next block
is operated on, so that the block operations have 'influence' on the
key stream. (Further, plain- and ciphertext chaining are provided.)
Thus one sees that in that kind of design stream and block techniques
are very intimately 'interwoven'.
> A way in which a cipher could be said to have "no keystream" would be
> if the keystream byte, rather than being generated from an internal
> state in a PRNG, is a function of the previous ciphertext bytes. This
> is similar to CFB mode of a block cipher. Since this has reasonable
> error-propagation qualities, it is used in practice.
A block cipher could be appropriately used as a PRNG. Further,
it could supply 'feed-back' to influence a PRNG, as indicated above
in my humble algorithm. So what is a 'key stream' could under
circumstances not be very sharply 'traced' to a source which one
could 'unambiguously' say is either a stream or block mechanism.
(This exact 'identification' is besides unnecessary in the first
place, if one takes on the 'unified' standpoint of combination of
'stream' and 'block' encryption techniques.) I am personally not in
favour of being too restrictive (or pedantic) in matters of
definitions, IN CASE some relaxation of definitions makes the
object of study much more easily accessible. (Incidentally, that's
one of the reasons why I don't like the idea of using the
'1 bit width' as the classification criterion for stream ciphers.)
M. K. Shen
===========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
** 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
******************************
