Cryptography-Digest Digest #643, Volume #9 Thu, 3 Jun 99 07:13:01 EDT
Contents:
Re: Oriental Language Based Enryption (Mok-Kong Shen)
Re: what cipher? (Terry Ritter)
Re: random numbers in ml ([EMAIL PROTECTED])
how do I make RSA keyring? (Bo Hedemark Pedersen)
Re: New Computer & Printer for Dave Scott (Matthew Skala)
Re: block ciphers vs stream ciphers (A. N. Alias)
Re: random numbers in ml ([EMAIL PROTECTED])
CRC32 (iLLusIOn)
Re: Viability of encrypted flash cards? ("Douglas A. Gwyn")
Re: Security ([EMAIL PROTECTED])
Re: what cipher? ("Douglas A. Gwyn")
Re: what cipher? (fungus)
Re: PGP probability of choosing primes? (Bob Silverman)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Oriental Language Based Enryption
Date: Wed, 02 Jun 1999 13:42:28 +0200
Patrick Juola wrote:
>
> You're not taking into account the translation process. The
> additional explicitness I cite isn't just a theoretical observation,
> but a practical one by made by linguists in the field -- and you
> can't blithely reverse the direction of the translation arrow.
We are considering (everyday) normal messages, not literal works, for
crypto purposes. So if the translation is good, one shouldn't be able
tell which is the original and which is the translation. Lots of
technical documents in multiple languages are excellent examples
of equivalent translations.
I think that even the concept of being an 'original' is questionable.
If I know two foreign languages to about the same extent and write
a business letter first in one language and after finishing it write
a version in the other language, do you also think that there
is some intrinsic difference between the two? (Here I myself am
the translator.) I suppose that you assume that a translation must
be poorer. This may be true for literary works, especially those
of famous writers. But for ordinary messages this shouldn't be the
case if the translator is a capable one (much depends on his
education, training, etc.) Of course, if someone who is poor in one
or even both of the languages attempts a translation, then the result
could be catastrophic. On the other hand there are plenty of people
fluent in several languages, some even grown up with two or three
languages.
>
> One of the sources of this additional explicitness is the necessity
> of setting the (target) text in a new cultural framework. There's
> a good example from the work of Baker (1997?) -- the sentence "The
> example of Truman was always on my mind," when translated into
> Arabic, turned into a complete paragraph that more or less explained
> to Arabic-speaking readers just who the hell Truman was. In general,
> any time you're doing any sort of writing, you are implicitly making
> expectations about the background of the reader -- and the more the
> (actual) readers differ from your assumed background, the more work
> the translator will need to put in to bring people up to speed.
You example is not appropriate in the current context. We are
considering the case where a message X is translated to Y, encrypted
then decrypted to Y and then translated back to X'. Here the people
involved know the context of the message. (In your example 'Truman'
would then simply become a phonetic equivalent of it in Arabic, nothing
more.)
>
> >The issue of being 'more explicit'
> >is not entirely clear to me.
>
> It's a question of what sort of explanatory information needs to be
> provided in the text.
I suppose that this is covered above.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: what cipher?
Date: Thu, 03 Jun 1999 04:36:41 GMT
On Wed, 2 Jun 1999 21:09:19 -0400, in
<[EMAIL PROTECTED]>, in sci.crypt "Particle"
<[EMAIL PROTECTED]> wrote:
>I'm looking for a stream cipher, or a block cipher
>that works in 8-bit intervals. (actually, I'm looking for
>the algorithm, I'm planning on implementing it myself)
>
>It is very important that the ciphertext retain the length
>of plain text.
It is extremely difficult to have a secure cipher which does not
expand the ciphertext to some extent. In particular, the usual
additive stream cipher must "never" re-use its ciphering or confusion
sequence. That means we need a different key for every "message," and
so probably implies at least a message key in addition to the data,
which thus expands the ciphertext.
There is some possibility of allowing some re-use of stream cipher
confusion sequences in ciphers which discard additive combiners like
exclusive-OR for table-based reversible nonlinear combiners such as
Dynamic Substitution. (Note: I own Dynamic Substitution technology.)
An ordinary 8-byte block cipher is universally considered too small to
use in ECB (electronic codebook) mode, and most chaining modes will
require at least an IV (initialization value) which will expand the
ciphertext. Even ECB mode would expand the ciphertext for messages
which are not an integral number of blocks. Even a 16-byte block
cipher is probably too small for ciphering language plaintext in ECB
mode.
The non-expansion requirement often comes up when ciphering low-level
disk storage. Fortunately, disk sectors normally have a length which
is an integral number of block cipher blocks. Many people have
attacked the problem by putting track and sector values into a hash,
which then provides a unique random-like key for each sector, so each
sector can be ciphered independently. But this is extremely risky if
ever the disk is replaced with the data copied without being first
deciphered (office machines are sometimes upgraded in just this way).
It is possible to have large block ciphers (e.g., Mixing Ciphers) with
a block size sufficient to generally avoid the ECB problem, although
they still have the usual problem with wasted space in the last block
with variable-size messages. (Note: I own Mixing Cipher technology.)
It is also possible to have variable size block ciphers (VSBC's) which
generally solve both the ECB problem and often can avoid wasted space
in the last block even with variable-size messages. If the last block
is too short for strength, data can be re-allocated from the preceding
block, *provided* that block is long enough. If not, there is not much
to be done. (Note: I own VSBC technology.)
But if you need to handle short and long messages without *any*
expansion at all, that will be very difficult.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.sys.cbm
Subject: Re: random numbers in ml
Date: 3 Jun 1999 05:11:30 GMT
Reply-To: [EMAIL PROTECTED] (Matthew Montchalin)
John Savard suggested the following 'C' pseudo-code:
| byte random(void)
|
| static byte seed[5]
| static byte temp1, temp2
|
| byte i,j
|
| i = seed[0] xor temp1
| temp1 = i >> 1
However, the Carry will be set at this point if seed[0] was odd, or clear
if seed[0] was even. Does the double >> operator reflect this? I am
unfamiliar with 'C' and find assembly language to be a lot more
straightforward, and *that* much easier to read.
| i = seed[0] + temp1
| seed[0] = temp1 + i <<< 1
Note that the Carry will now be set if 255<temp1 + i, or clear if
256>temp1 + i. This is important because the Carry will affect the next
operation.
| i = seed[1] xor temp2
| temp2 = i >>> 1
| i = seed[1] + temp2
| seed[1] = temp2 + i <<< 1
|
| i = seed[0]
| for j = 0 to 3
| seed[j] = seed[j+1]
| next j
|
| seed[4] = i
Shouldn't this be seed[4] = seed[4] + i ?
| return i
Note that the Carry is apparently random at this point. Thus, the
variable 'i' should be 9 bits wide. Does 'C' support variables that
are 9 bits wide? Sorry for being so naive.
| but if rol does a nine-bit rotate, including the carry bit, then your
| actual routine would be somewhat different.
Eyup. :)
Can you or anybody suggest what the likely period is for this algorithm?
By saying 'period,' I mean, how long it will take for the routine to
repeat, if ever. Short of that, if the routine settles down into an
infinite pattern, how long does it take to do that? My guess is that the
routine does not start repeating until a very large number of iterations
(uh, well, maybe 2^56) have passed. Again, it is only a guess, and what
seems really random at one point can seem really predictable at another
point. It is quite possible that I just haven't looked at the thing from
the *right* perspective yet.
--
------------------------------
From: Bo Hedemark Pedersen <[EMAIL PROTECTED]>
Subject: how do I make RSA keyring?
Date: Thu, 03 Jun 1999 08:15:03 +0200
In my IIS-keymanager, I'm restricted to making 512-bit RSA keys. Does
any freeware capable of constructing 1024-bit (or higher) RSA requests
and certificates exist?
Thanks,
Bo
------------------------------
From: [EMAIL PROTECTED] (Matthew Skala)
Subject: Re: New Computer & Printer for Dave Scott
Date: 2 Jun 1999 10:07:28 -0700
In article <TDc53.929$[EMAIL PROTECTED]>,
Gus James <[EMAIL PROTECTED]> wrote:
>computer and an inkjet printer to David A. Scott? I believe that if he was
>not hampered by the primitive hardware he works on, he could perhaps improve
>the legibility of his code. It would certainly inspire him to make the next
Tuition for some English composition classes would help a lot more, and I
think (based on Scott's own statements) that he wouldn't accept that. Give
him a faster computer and he'll write a slower algorithm.
--
Free laser networking and other crazy ideas @
http://www.islandnet.com/~mskala/netfree.html
------------------------------
Subject: Re: block ciphers vs stream ciphers
From: [EMAIL PROTECTED] (A. N. Alias)
Date: Thu, 03 Jun 1999 07:03:34 GMT
In article <7j3m81$[EMAIL PROTECTED]>,
Scott Fluhrer <[EMAIL PROTECTED]> wrote:
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>
>>DJohn37050 wrote:
>>> There are 2 well-studied modes of operation of a block cipher (OFB
>>> and CFB) that create a stream cipher. Going in the other direction
>>> is more problematic.
>>
>>No, it is easy to use a stream cipher in block mode, and unlike the
>>converse case, no security is lost in doing so.
>>
>I haven't heard this before. Could you give an outline of how this is
>done, or possibly a reference?
Not have I, and I'm also quite interested in seeing that construction.
However, in Eurocrypt '98 there is a paper ("The chain & sum primitive and
its applications to MACs and stream ciphers") that discusses something
similar, namely a method of adding integrity to stream ciphers by
preprocessing the plaintext with a CBC-like primitive. This still keeps
the speed of stream ciphers while adding integrity properties reminiscent
of block ciphers in CBC mode.
--
A. N. Alias -- [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.sys.cbm
Subject: Re: random numbers in ml
Date: 3 Jun 1999 07:06:16 GMT
Reply-To: [EMAIL PROTECTED] (Matthew Montchalin)
The source code being:
| 110random lda seed eor temp lsr sta temp
| 120 adc seed rol adc temp sta seed
| 130
| 140 lda seed+1 eor temp+1 ror sta temp+1
| 150 adc seed+1 rol adc temp+1 sta seed+1
| 160
| 170 adc seed+4
| 180
| 190 pha
| 200 mov seed+1 seed
| 210 mov seed+2 seed+1
| 220 mov seed+3 seed+2
| 230 mov seed+4 seed+3
| 240 pla
| 250
| 260 sta seed+4
| 270 rts
| 280
| 290seed hex 00 00 00 00 00 ; five bytes
| 300
| 310temp hex 00 00 ; two bytes
| 320
| 330; ________________________________________________________________
| 340; | |
| 350; | If your symbolic assembler can't handle multiple instructions |
| 360; | per line of source code, get a better assembler. |
| 370; | |
| 380; | Random Number Generator |
| 390; | |
| 400; | by |
| 410; | |
| 420; | Matthew Montchalin |
| 430; | |
| 440; |________________________________________________________________|
I plugged in the following seed: $00 $00 $00 $00 $01 (sort of a worst
case scenario for a seed) and zeroed out the two bytes at temp, and then
got the following results for the first 64 bytes generated:
00-07 : 01, 01, 01, 05, 09, 0d, 11, 23
08-0f : 46, 6c, ae, b4, 7c, 5c, bb, 77
10-17 : 84, c4, 9d, 27, b7, 9e, 37, 02
18-1f : 5e, d5, d2, 9b, 84, 39, ad, 31
20-27 : 9c, 02, 6e, 1e, 1a, 49, fb, bd
28-2f : d5, 7e, 71, 51, 6b, 6e, fe, 3d
30-37 : 23, a3, cd, 92, 2f, 93, 09, 77
38-3f : 38, 6b, f5, f3, 47, 4e, 92, 3b
Although Bit 7 looks pretty light, let me assure you that this is a
temporary (er, ah, local) effect, and the thing does improve in the course
of the next 64 bytes. :)
So now I try out the seed $e7, $00, $00, $00, $00 (the alternative
worst-case scenario (?) for a seed that is light on 1 bits), and I got the
following 64 bytes:
00-07 : 81, c3, e4, 74, 82, f2, b9, d2
08-0f : b2, 32, 3c, 31, 3b, dd, 57, a3
10-17 : 4c, 21, 27, a8, 76, 05, 32, d6
18-1f : e8, 00, 06, 09, c0, 32, 6e, a6
20-27 : 59, 3b, 7e, 92, 6d, 34, c9, 5f
28-2f : 56, 5e, 6c, 5c, f3, 2d, 20, d9
30-37 : 46, a2, 12, f3, b2, 05, 1c, 84
38-3f : d0, 48, d4, 42, 0d, 06, 23, fd
The only thing that seems apparent right now is how light Bit 7 comes out.
But the fact is, this straightens out as more numbers are generated, and
the seed 'dirties' up.
--
------------------------------
Date: 3 Jun 1999 07:54:22 -0000
From: iLLusIOn <Use-Author-Address-Header@[127.1]>
Subject: CRC32
=====BEGIN PGP SIGNED MESSAGE=====
Hello,
I'm looking for any texts/urls with algorithms and descriptions
of CRC-32 (like used in zip files for example), I have found a few
sites providing source code but none which provide really useful
descriptions of how/why it works. anything appreciated :)
are there any ways to speed crc32 up a bit? or are there any
faster (yet as "secure") algorithms as crc32? how high is the
possibility that i'd get the same checksum twice? my
implementation would be used to generate checksums of many
files, getting the same checksum on two different files would be
bad.
tia
~~~
This PGP signature only certifies the sender and date of the message.
It implies no approval from the administrators of nym.alias.net.
Date: Thu Jun 3 07:54:19 1999 GMT
From: [EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: 2.6.2
iQEVAwUBN1Y0rU5NDhYLYPHNAQEEAQf+IWtNZS0IjjVX9bfWh7jYp4cBJrWyqw96
0x8cbIYRMcWmOsr3Xsf0RQ6HkrRPGLm+Kkqjca11E0xwqNmUfWZorvprqGwvDATA
JU5Gbv0s5Hw8TXKSGShnqnnfk6tZnMyYw4IjWCbcyPETYSdInOruqbl2XzqI9OQX
Zj8K/CK0wN+O6mVAV9O/SmWSufwklMTv5lPTkUYMHqIEJjHmuMs7OgWTS0R4cn3t
oJ+tBda/DFwAhhPQNaVHOnlIDdfoj/F9AVoNKQq0q3NmeGbk4W71LUP9TAHGdCcl
jaHQ55hyvt4SYR67w40OgBhoEo0N+0JqUtQ1QswP24PRJcr+2Tgdfw==
=T0LD
=====END PGP SIGNATURE=====
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: alt.security,talk.politics.crypto
Subject: Re: Viability of encrypted flash cards?
Date: Thu, 03 Jun 1999 09:45:53 GMT
Phil Hunt wrote:
> But it's true! The innocent have nothing to fear.
Spoken like a true victim.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Security
Date: Tue, 01 Jun 1999 18:04:38 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (wtshaw) wrote:
> In article <[EMAIL PROTECTED]>, Bryan Olson
> <[EMAIL PROTECTED]> wrote:
> >
> > With an ideal cipher, we expect a unique solution at about
> > the point where the redundancy in the text is equal to the
> > entropy of the key (here we mean the redudancy in bits, not
> > the percentage). The random padding that extends each byte
> > to a block makes the amount of redundancy in each block the
> > same as the amount of redundancy in the original byte. The
> > padding has zero redundancy and the byte hasn't lost any.
> > With an ideal cipher, we expect a unique solution at about
> > the point where the redundancy in the text is equal to the
> > entropy of the key.
> >
> Being conditioned to having padding added at the end it unfortunate.
And has nothing to do with the issue here.
> There is no reason that padding could not be at the beginning or any
other
> place, or in more than one place. The nature of the of the padding
should
> make it obvious regardless of its placement upon proper decryption.
Not
> knowing where the padding occurs means attacking a cipher with assumed
> inserted nulls, which is not the same as one without them..
Doesn't effect the result. If the intended recipient can
remove the padding, so can the attacker. He just needs
enough ciphertext so that there is only one legal message.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: what cipher?
Date: Thu, 03 Jun 1999 09:58:39 GMT
Terry Ritter wrote:
> It is extremely difficult to have a secure cipher which does not
> expand the ciphertext to some extent. In particular, the usual
> additive stream cipher must "never" re-use its ciphering or confusion
> sequence. That means we need a different key for every "message," and
> so probably implies at least a message key in addition to the data,
> which thus expands the ciphertext.
Good stream ciphers aren't normally additive-key systems; the stock
example is a feedback shift register, where plaintext feeds one end
and ciphertext is produced at the other end. (The key determines
the initial fill and some of the feedback parameters.)
It is easy enough to combine the (variable) message sequence number
with the (fixed) key to produce a different set of cryptovariables
for each message.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: what cipher?
Date: Thu, 03 Jun 1999 12:10:22 +0200
Brian Hetrick wrote:
>
> Pick a block cipher, set it up on OFB mode, and voila! a stream
> cipher.
...except slower and harder to program.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: PGP probability of choosing primes?
Date: Mon, 31 May 1999 21:58:43 GMT
In article <7iq213$k7$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Bill Unruh) wrote:
> mathamatical question:
> As I recall, PGP chooses its primes by choosing a random number of L/2
> bits (L is the length of the modulus N) It makes sure it is odd, and
> then tests it for primality. If it is not prime, it adds two and tries
> again. Now, this would make the selection of primes which follow a long
> stretch of non-primes much more likely that a prime with another prime
> close by but smaller. (Teh relative probability is proportional to the
> number of non-primes between that prime and the immediately smaller
> prime). Does anyone know what the distribution of distances between
> primes is for numbers of lenth L/2?
No. Noone does. It is an unsolved, open, mathematical problem.
It is known, however, that most of the prime gaps will be about
log(L/2) (the Prime Number Theorem would be false, otherwise).
Exceptions are rather rare. It is known, for example, that as L -->oo
the set of primes which are preceeded by a gap less than any fixed
power of loglog L have density 0. It is not known, however,
how many primes are preceded by a gap of about (log L)^delta
for delta < 1.
> How much does this weaken PGP?
Zero. In fact, the question assumes that an attack would depend on the size
of the keyspace and that somehow an incremental search procedure (as used by
PGP) reduces the size of that space in a measureable way. It would be
impossible to measure exactly the reduction in keysapce caused by an
incremental search procedure, but it would be TINY. Firstly, the procedure
really doesn't reduce the keyspace. It simply makes some keys more likely
that others. Secondly, there are ~ 3.7 x 10^151 512 bit primes. The set of
primes which have a low probability of being selected are only a very tiny
fraction of these.
Further, a direct search attack would indeed
depend on the size of the keyspace, But the size of the keyspace
is SO large, that factoring attacks are much more efficient. And
factoring attacks do not care one whit how the primes were
generated.
generated.
> Do primes which have a large distance from the next smallest prime have any
> peculiar features that might make them more susceptible to being
> cracked?
What did you have in mind? The Number Field Sieve (the fastest
factoring attack) only depends on the size of the number being
factored. That the size of the modulus does not depend on
how the primes were selected. Other, special purpose attacks
are worse than useless on numbers of this size.
And the short answer to your question is: NO. They have
no special features.
(The average distance between primes of length L is roughly
> ln(L), but what is the distribution?
Solve that problem and win the Fields Medal.
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
