Cryptography-Digest Digest #870, Volume #9 Mon, 12 Jul 99 12:13:02 EDT
Contents:
Re: How Big is a Byte? (was: New Encryption Product!) ("Douglas A. Gwyn")
Re: Possible Extension for Block Ciphers (Mok-Kong Shen)
Re: Base encryption (Mok-Kong Shen)
Re: Uncrackable? (James Andrews)
Re: Uncrackable? (James Andrews)
Re: Uncrackable? (mok-kong shen)
Re: Uncrackable? (James Andrews)
Re: New Encryption Product! (humor) ("Kurt Mueller")
Re: How Big is a Byte? (was: New Encryption Product!) (John Savard)
Re: Stream Cipher != PRNG (John Savard)
Re: Uncrackable? (mok-kong shen)
Re: Electronically Exporting crypto source (legally) (Alan J Rosenthal)
Re: Help with RNG Stats (mok-kong shen)
Re: How Big is a Byte? (was: New Encryption Product!) (Eric J. Korpela)
Re: New Encryption Product! (humor) ("Juergen Nieveler / CompuNet")
Re: How Big is a Byte? (was: New Encryption Product!) (Eric J. Korpela)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Mon, 12 Jul 1999 09:37:42 GMT
Dennis Ritchie wrote:
> The earliest reference to the term I have in hand is "Planning a
> Computer System", ed. Werner Buchholz, McGraw-Hill, 1962.
CDC mainframes, and even their minicomputer (CDC 1700),
had variable-length byte operands for several opcodes.
CDC didn't necessarily associate "byte" with "character";
for them a byte was just a contiguous stretch of bits
to be operated on.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Possible Extension for Block Ciphers
Date: Mon, 12 Jul 1999 12:58:38 +0200
[EMAIL PROTECTED] wrote:
> Hmm neato. Basically though I think you are mixing pre-white keys.
> What I am doing is splitting the larger input into parts. I will look
> at your site though.
Please look at the text part of all three articles numbered 12, 14, 15
on my main web page. Quite a number of (known) techniques (possibly
with some minute variations of mine) are integrated in my scheme.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Base encryption
Date: Mon, 12 Jul 1999 10:37:40 +0200
User wrote:
>
> Humans in the Eastern asian hemisphere are used to a larger "base"
> (or character set). There are over 60,000 unique symbols in the
> Chinese language (while the roman alphabet has less than 64!!).
These ideographs are individually words. Very often pairs or triples
of ideographs correspond to words in the sense of European languages.
Each ideograph is in turn built of a small set of building blocks,
the so-called strokes, e.g. a vertical line, a point, etc.
In the European languages the building blocks of words are the
alphabetical characters. Thus I am not sure that your comparison
of 60000 to 64 is very appropriate.
On the other hand, the Chinese telegraphic code maps a subset of
the words to 4 decimal digits. Via Unicode every Chinese ideograph
has a 2 byte binary value. This has no correspondce for the words
in the European languages. I said a couple of times previously that
if there were a commonly accepted (quasi-standard) numerical encoding
of English words, e.g. if a publisher of a big dictionary would
associate a number to each word, then in the thus numerically
encoded plaintext frequency analysis would be comparatively much
more difficult to perform than in the case with the alphabets.
On the other hand, of couse, modern cryptographical techniques
have substantially reduced the value of frequency analysis, I believe.
>
> If you were to take the front page of a chinese newspaper to a person
> who had no exposure to chinese before, it is extremely difficult for them
> to understand it (take the pictures out of course). Take this also into
> consideration... you cannot easily guess the base of this example
> because the front page only contains a subset of the greater than
> 60,000 unique symbols in the Chinese language.
This argument is not valid, I am afraid. Could you read e.g. a
newspaper, say, of Bulgaria, more easily than a Chinese one?
M. K. Shen
------------------------------
From: James Andrews <[EMAIL PROTECTED]>
Subject: Re: Uncrackable?
Date: Mon, 12 Jul 1999 14:04:45 +0000
Reply-To: [EMAIL PROTECTED]
wtshaw wrote:
> Regardless of what is said, please keep your interest. Secure and
> Infinity are difficult targets, good luck to you if you plan to get them
> under your thumb. Actually, you have some good ideas in your posting
> (chronic readers will notice those which I have supported).
Thanks, I dont expect this algorithm to revolutionise the world of cryptology, its
merely an interest I've aquired, one I'd
like to continue developing. I have a few questions, mostly based on the comments of
Tom.
If XOR-ADD-XOR builds a linear equation, how about pseudo-random application and
ordering of the streams? If it were,
however, to use further information from the stream, to decide which order the streams
will be applied, or if all the
streams will be used at all for this byte, and which operator will be used for each
combination. It is still reversible,
but the pattern would be anything but linear. There may be an overall linear equation
which could be applied to the entire
process for one given key, but it would be different for most keys. The password could
also be compressed into a smaller
subset of characters to increase the scope of it. The random streams could be
increased slightly in number to lower the
impact of the data on the statistical analysis of the encrypted data. The random
seeds generated could be used to generate
further integers as seeds to allow more than 3 streams with smaller key's still giving
reasonable encryption. The down
side of keeping the key size low is the simplicity of a brute-force aproach. Although
with no internal marker of
correctness, and I'm sure at least 2^32 passwords, at least a couple of hundred files
would result with dictionary words, I
suspect more. Of course such a method could very easily just use a pseudo-random
block of data to represent a key to make
brute-force a bit unreasonable. Any thoughts?
James
------------------------------
From: James Andrews <[EMAIL PROTECTED]>
Subject: Re: Uncrackable?
Date: Mon, 12 Jul 1999 15:42:21 +0000
Reply-To: [EMAIL PROTECTED]
mok-kong shen wrote:
> You might be interested in a compound PRNG designed by me where
> a number of constituent PRNGs are activated in an order determined
> by the output of these themselves. In encryption algorithms using
> that the output of the compound PRNG (real numbers in [0,1)) is,
> as a user option, further combined with addition mod 1 (several
> consecutive outputs added together and taking the fractional part,
> an idea due to Wichmann and Hill). See
>
> http://www.stud.uni-muenchen.de/~mok-kong.shen/#paper9
No lack of research or information on those pages ;-). I can see you know far more on
the subject than me, but I'm working on
a much simpler theory. I was thinking more in the way of diffusion by operator type.
If you revert back to the pseudo-random
streams spewing out 32-bit integers as most do, then a very simple method would be to
use various operators dependant on the
results of another stream. There are quite a large variety of bi-directional
operators with complete domain and range so they
shouldnt adjust the encrypted data statistically in any noticable way. Possible
operators to use could include arithmetic
shifts (both directions), addition, subtraction and exclusive or. Secondly because
these functions affect each byte in turn,
no two files would show up as having anything in common, so I'd imagine two encrypted
files would bare no resemblance even if
they used the same key, this is however still theoretical and subject to
investigation. I'll put together a simple
encoder/decoder of the above idea in Java later if anyone wants to see it. Could be
interesting,
I wonder if some of the decryption details could be in the file itself in some way? I
remember reading that an accepted
aspect of security is that the longer the algorithm takes to decrypt, the more secure,
at least from the perspective of
brute-force, maybe if the client, knowing the password still had to do a little
breaking itself to decrypt the file, however
little. You could have a trail of numbers, generated by a random seed which follows
them. The client would have to search
through each possible seed till one generated all the numbers leading up to itself.
Since any attempts to hack the file would
require to search in this manner through the entire file with each iteration it would
increase the performance required for a
brute-force hack by a noticable amount. Just a few thoughts,
James
------------------------------
From: mok-kong shen <[EMAIL PROTECTED]>
Subject: Re: Uncrackable?
Date: Mon, 12 Jul 1999 14:41:51 +0200
[EMAIL PROTECTED] wrote:
>
> Using three PRNGs in a 'mixing' mode of C = ((P + PRNG1) xor PRNG2) +
> PRNG3 is not really strong. There is a linear equation for the first
> bit that holds with p=1, then with this the rest of the carry bits can
> be attacked. With this a divide and conquer attack can get the rest.
One can improve by introducing a pseudo-randomly determined cyclic
rotation of the bits in a word. Disregarding the variations (XOR vs.
+), P is encrypted with the 'combined' output of three generators.
The idea of combination of outputs of (any number of) PRNGs stems
from Wichmann and Hill, who showed that the combined sequence is
more uniform than the component sequences.
M. K. Shen
============================
http://www.stud.uni-muenchen.de/~mok-kong.shen/ (Updated: 12 Apr 99)
------------------------------
From: James Andrews <[EMAIL PROTECTED]>
Subject: Re: Uncrackable?
Date: Mon, 12 Jul 1999 16:01:36 +0000
Reply-To: [EMAIL PROTECTED]
The random number generator itself seems to generate unbiased results, but would the
same effect be achieved if/when combined
using any/all of the operators I mentioned in the last post? If you dont mind let me
know and I'll try a java conversion and try
implementing it as the source of the ideas in my last post. Sorry if this seems to be
a contradictory post to my last one, I was
reading too fast and thought the pages were about something completely different (dont
ask, I havent been sleeping much :-P),
James
------------------------------
From: "Kurt Mueller" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: New Encryption Product! (humor)
Date: Mon, 12 Jul 1999 10:06:43 -0400
Juergen Nieveler / CompuNet wrote in message <7mc6mc$[EMAIL PROTECTED]>...
>256 is 2 times 128, it�s got to be a lot safer ;-)))
With regard to key sizes, 256 is not twice as big as
128. 129 is twice as big as 128. Because it is 2^128
vs. 2^129. As you can see, the increase of the power
means one more multiplication of two, so each successive
number is twice as big as the one before, making 256
2^128 times more secure then 128 bit crypto. That's
pretty secure! But remember, key size isn't everything
in the crypto game. You would be hard pressed, for
example, to have a secure enough passphrase to protect
a key so large. 128 bit isn't breakable, neither is 256.
It is much easier to go after other weaknesses in the
system if you really want the information.
--
_____________________
Kurt Mueller
[EMAIL PROTECTED]
PGP encrypted mail highly preferred! DH preferred! Get my keys at:
http://www.bigfoot.com/~wwww
Signed. Sealed. Delivered.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Mon, 12 Jul 1999 15:05:29 GMT
[EMAIL PROTECTED] (Paul Schlyter) wrote, in part:
>You should read the manuals to some old mainframe computers, e.g. the
>DEC-10 where bytes could be 7, 8 or even 9 bits
Although I'm well aware that many old mainframe computers had 6 bit
_characters_, I didn't realize that the PDP-10 did use the term "byte"
in referring to its variable-length character feature in its
documentation.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Stream Cipher != PRNG
Date: Mon, 12 Jul 1999 15:12:56 GMT
[EMAIL PROTECTED] wrote, in part:
>Finally that makes sense. So basically the PRNG is only one building
>block (like a key schedule in a block cipher). What if the PRNG is
>inherantly intractable though (like BBS) there is no combiner then?
The combiner might just be a simple XOR, and in that case the stream
cipher and its associated PRNG might have the same name.
But as DAG has pointed out, there are other ways of having stream
ciphers that don't involve a PRNG at all, as I also noted by
describing the "self-synchronizing" type of stream cipher, where a
function of several previous ciphertext bytes is applied to each byte
of plaintext to encipher it.
Essentially, this is similar to the block cipher mode known as CFB,
for Cipher FeedBack.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: mok-kong shen <[EMAIL PROTECTED]>
Subject: Re: Uncrackable?
Date: Mon, 12 Jul 1999 17:12:51 +0200
James Andrews wrote:
>
> I was thinking more in the way of diffusion by operator type. If you revert back to
>the pseudo-random
> streams spewing out 32-bit integers as most do, then a very simple method would be
>to use various operators dependant on the
> results of another stream. There are quite a large variety of bi-directional
>operators with complete domain and range so they
> shouldnt adjust the encrypted data statistically in any noticable way. Possible
>operators to use could include arithmetic
> shifts (both directions), addition, subtraction and exclusive or. Secondly because
>these functions affect each byte in turn,
> no two files would show up as having anything in common, so I'd imagine two
>encrypted files would bare no resemblance even if
> they used the same key, this is however still theoretical and subject to
>investigation. I'll put together a simple
> encoder/decoder of the above idea in Java later if anyone wants to see it. Could be
>interesting,
The idea of using a large set of (varaible, hence for the analyst
difficult to infer) operations is basically sound. You can use
a PRNG stream to determine the choice of these operations everywhere
an operation is to be done. However, that is a bit costly, though
could certainly be justified in really critical applications. In my
compound PRNG (itself) I don't consider using any variable operations,
since its output is utilized (in my WEAK3-EX) in an algorithm which
is a mixture of stream and block encryption and where there is
ample 'variability' designed in to defeat attempts of analysis. BTW,
circular shift is better than arithmetic shift in my humble view.
>
> I wonder if some of the decryption details could be in the file itself in some way?
>I remember reading that an accepted
> aspect of security is that the longer the algorithm takes to decrypt, the more
>secure, at least from the perspective of
> brute-force, maybe if the client, knowing the password still had to do a little
>breaking itself to decrypt the file, however
> little. You could have a trail of numbers, generated by a random seed which follows
>them. The client would have to search
> through each possible seed till one generated all the numbers leading up to itself.
>Since any attempts to hack the file would
> require to search in this manner through the entire file with each iteration it
>would increase the performance required for a
> brute-force hack by a noticable amount. Just a few thoughts,
If the design of an algorithm is such that brute force is the most
promising approach of analysis, then increasing the processing time
is a viable and effective means of increasing the strength, since the
analyst has to spend a very large multiple of the time that the
legitimate communication partners spend to encrypt/decrypt. I exploit
that in my WEAK-EX series of algorithms and call that presumably new
paradigm 'Security through Inefficiency' (see the text of my article
on WEAK3-EX).
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Alan J Rosenthal)
Subject: Re: Electronically Exporting crypto source (legally)
Date: 12 Jul 99 15:13:34 GMT
[EMAIL PROTECTED] (Dmitri Alperovitch) writes:
>So, then you should be able to slice your program apart into lines or even
>bigger chunks of code that do not contain a fully working cryptographic
>algorithm and it should be legal to electronically export each of these chunks
>individually!
Each, but not all. Exporting one of them is fine, but useless. Exporting
them all constitutes exporting the entire program. Your reductionism is
leading you astray.
Dialling '9' by itself on the telephone for no reason is acceptable behaviour.
Dialling '1' by itself on the telephone for no reason is acceptable behaviour.
Dialling '1' by itself on the telephone for no reason is acceptable behaviour.
However, dialing 9, 1, 1 in sequence (emergency call, fire/police/etc) for
no reason is not permitted. No contradiction. You can't just focus on the
individual parts and refuse to see the overall structure.
------------------------------
From: mok-kong shen <[EMAIL PROTECTED]>
Subject: Re: Help with RNG Stats
Date: Mon, 12 Jul 1999 16:47:28 +0200
Clinton Begin wrote:
>
> I need the opinion of a math genius or two. Below are the DIEHARD
> results for my random number generator. I would like to use this RNG
The Diehard package was not bug-free. I am ignorant of its current
status. Maurer's universal statistical test is easy to implement
and interpret.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Eric J. Korpela)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: 12 Jul 1999 15:29:27 GMT
In article <[EMAIL PROTECTED]>,
Gergo Barany <[EMAIL PROTECTED]> wrote:
>In article <7mal54$khv$[EMAIL PROTECTED]>, Eric J. Korpela wrote:
>>In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>>>However, AFAIK, that is the *only* place the term byte has ever been used
>>>to describe anything other than an (ahem) octet
>>
>>I believe that the current C standard uses the term byte to mean the minimum
>>addressable unit of storage (i.e. the unit of storage in which a "char" will
>>fit.) Number of bits is only specified by lower bound.
>
>The number of bits is specified by the CHAR_BIT macro in limits.h.
I meant specified by the C standard. IIRC, the C standard specifies that
char must be able to hold at least 256 (or is it 255?) unique values.
I didn't mean it is indeterminable.
CHAR_BIT isn't a specification, it's a value defined by the implementation.
Eric
--
Eric Korpela | An object at rest can never be
[EMAIL PROTECTED] | stopped.
<a href="http://sag-www.ssl.berkeley.edu/~korpela">Click for home page.</a>
------------------------------
From: "Juergen Nieveler / CompuNet" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: New Encryption Product! (humor)
Date: Mon, 12 Jul 1999 17:27:18 +0100
Kurt Mueller <[EMAIL PROTECTED]> schrieb in im Newsbeitrag:
7mcsls$j0c$[EMAIL PROTECTED]
> It is much easier to go after other weaknesses in the
> system if you really want the information.
>
You do know what 256xROT13 is, don�t you?
Grin, duck & run ;-)))
--
Mit freundlichen Gr��en / Yours sincerely
Juergen Nieveler
CompuNet
[EMAIL PROTECTED]
Disclaimer: Views are mine, not my employers�
------------------------------
From: [EMAIL PROTECTED] (Eric J. Korpela)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: 12 Jul 1999 15:34:25 GMT
In article <7matvg$p1o$[EMAIL PROTECTED]>,
Paul Schlyter <[EMAIL PROTECTED]> wrote:
>Does this mean that a C implementation on the Cray supercomputer
>must have 64-bit chars?
No, but the virtual machine must look as if it can address single byte
units. (i.e. a "char *" must have enough information to uniquely point
to a char, and of course pointer arithmetic must still work properly).
Eric
--
Eric Korpela | An object at rest can never be
[EMAIL PROTECTED] | stopped.
<a href="http://sag-www.ssl.berkeley.edu/~korpela">Click for home page.</a>
------------------------------
** 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
******************************
