Cryptography-Digest Digest #351, Volume #11 Fri, 17 Mar 00 00:13:01 EST
Contents:
Re: Improvement on Von Neumann compensator? (Scott Nelson)
Re: Enigma encryption updated (Adam D) ("Joseph Ashwood")
Re: Cellular automata based public key cryptography (Tim Tyler)
Re: new/old encryption technique (Arthur Dardia)
Re: my toy cipher ("Joseph Ashwood")
Re: SALT with RC4, where do I store the SALT? (Johnny Bravo)
Re: Enigma encryption updated (Adam D) (stanislav shalunov)
Re: SALT with RC4, where do I store the SALT? (Impervious)
Re: Enigma encryption updated (Adam D) (Nemo psj)
Micro Stream Cipher (Tom St Denis)
Re: SALT with RC4, where do I store the SALT? (Johnny Bravo)
Re: EOF in cipher??? ("Douglas A. Gwyn")
Re: Universal Language ([EMAIL PROTECTED])
Re: On jamming interception networks ("Douglas A. Gwyn")
Re: Enigma encryption updated (Adam D) ("Joseph Ashwood")
Re: Universal Language (stanislav shalunov)
Re: Enigma encryption updated (Adam D) (stanislav shalunov)
Re: Enigma encryption updated (Adam D) ("Joseph Ashwood")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Improvement on Von Neumann compensator?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 17 Mar 2000 01:16:32 GMT
On Thu, 16 Mar 2000 15:17:44 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>Guy Macon <[EMAIL PROTECTED]> wrote:
>: I know that if I XOR a true random bitstream with any other bitstream
>: (except those derived from the true random bitstream), the result
>: will be a true random bitstream. Can this property be proven for
>: any cryptologically strong hash functions such as SHA1?
>
>It can be practically proven false - the hash of a fixed-length finite
>random bitstream is never itself random - though it can become /very/
>nearly so.
For CRC, that's provably false.
CRC has a _perfectly_ flat distribution.
For small CRC's this can be proven by simply
calculating the CRC of all N bit streams -
There will be exactly N outputs.
If at any time, there are N perfectly
random bits in a row in the stream,
then CRC of that stream is also perfectly random.
It's possible for a secure hashing function to have
the same property. For example;
Use Twofish to crypt the first 16 bytes with a fixed key.
XOR the output with the key and the next 16 bytes,
and crypt again. Repeat until all bytes are used.
I don't think SHA1 has this property, but I do believe
it's flatter than a "random" hash would be. (a hash
that maps inputs to outputs at random)
But even with a "random" hash we'd expect all 2^160
possible input strings to hash to 2^160/e output strings
- a loss of less than 1.5 bits, or .991 "real" bits per
bit. If previous values are hashed with future ones,
this bias quickly approaches 0. While it never gets there
in the mathematical sense, in the engineering sense
it gets close enough for all practical purposes.
Scott Nelson <[EMAIL PROTECTED]>
- Don't forget to vote on sci.crypt.random-numbers
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Enigma encryption updated (Adam D)
Date: Thu, 16 Mar 2000 18:07:03 -0000
You still seem to have some problems with your algorithm.
Most importantly your algorithm is presented in such a
manner that your intent is clearly to make it more complex
than it actually is (or you have no idea how to deal with
algorithms). You algorithm is as follows, and as I informed
you before.
(to encrypt a single byte b)
For each character c in the password
{
b = (b+c) mod 256
if b is odd
b = b-1
else
b = b+1
}
Somehow it seems to me that this uses a massive amount less
RAM than your method. It also shows that the maximum
protection offered by a password is 8 bits on each byte.
It's security is lower than that of ARC4, it's slower than
ARC4, it is more encumbered than ARC4. I'm still not
impressed., and I'm even less impressed with your
algorithmic abilities, it took me less time to come up with
the far more optimal algorithm than it took me to write it
down.
For more analysis read on:
The last if b is odd part is of no cryptographic value, so
it can be eliminated easily. The rest is simple addition,
which as we know if your key schedule is truly strong is
sufficient, but yet you have failed to demonstrate the
ability to choose a key schedule that is strong enough,
since you have performed no analysis of how your RC4 method
interacts with your own designs, which by the way it
interacts in a rather poor way. Let's take for example
several passwords, and replacing your claimed-RC4 with a
random permutation oracle with the same behavior as RC4 for
simplicity.
1-byte password:
First encryption reveals password completely
2-byte password:
first encryption reveals the sum of the two bytes
second encryption adds a number with very strong tendancies
towards being <64, but also supplies us very neatly with
only the previous key (all 8 bits of it) and a small value
etc.
It's very weak
3-byte password:
same as 2-byte password
n-byte password:
same as 2-byte password
for those of you that are keeping count that means a 16-bit
password. These are the same things I said last time, and
these are the same things I will say next time. THE
ALGORITHM ITSELF IS WEAK.
Joe
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Cellular automata based public key cryptography
Reply-To: [EMAIL PROTECTED]
Date: Fri, 17 Mar 2000 01:57:52 GMT
James Felling <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Boris Kolar <[EMAIL PROTECTED]> wrote:
:> : Tim Tyler <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> :> Boris Kolar <[EMAIL PROTECTED]> wrote:
:> :> : Tim Tyler <[EMAIL PROTECTED]> wrote in message
:> :> :> To confuse matters, I'll mention that there *is* a sense in which an
:> :> :> infinite cellular automata can be *more* powerful than a Turing
:> :> :> machine(!)
:> :> :>
:> :> :> A Turing machine can only do one thing at a time. [...]
:> :> :>
:> :> :> An infinite cellular automata can do lots of things simultaneously.
:> :> :> Given certain types of function with an infinite input, and requiring
:> :> :> an infinite output, it can calculate the results in a finite time.
:> :> :> By contrast, a TM would never even finish reading in all the inputs,
:> :> :> let alone process them.
:> :> :>
:> :> :> Consequently there are types of calculations a CA can perform, which a
:> :> :> TM cannot ;-)
:> :>
:> :> : Not true. CA is of course "faster" than TM, but they are equivalent in
:> :> : power. [...]
: Assuming that the CA is operating on a countable (Aleph null) grid the CA is
: faster but exactly equivalent to a TM
: The reason for this being that there is a direct map from an n-dimensional
: infinity to a 1 dimensional infinity which is effectively what a TM
: operates on.
I don't believe that this follows. A 1D CA can still compute functions
which a TM can never compute.
The problem with the TM is that it can only do one thing at a time.
A system which operates on a 1D line one step at a time is weaker than one
that processes an infinite number of operations simultaneously, when
evaluating some functions with infinite numbers of inputs and outputs.
Yes, a 1D CA can simulate an n-dimensional one - but equating a 1D CA
to a TM is not a valid step.
:> :> What about the type of calculation I mentioned? A CA can perform these
:> :> in a finite time, while a Turing machine cannot ever perform them.
: The CA operating on a countable grid will still be vulnerable to a
: diagonalization argument, which means that it will NOT be capable
: of resolving the halting problem in finite time.
I agree here.
: If the grid is uncountable then yes the halting problem will fall.
I'm not familiar with any "uncountable grid"s.
:> :> If one system can do rapidly something that the other cannot /ever/ do,
:> :> in what sense are they "equivalent in power"?
: In the case of a countable CM they are exactly equivalent. [...]
This is a flat assertion, not an answer to the question. How can they
possibly be "exactly equivalent" when one can compute something the
other cannot?
Ob cryptography: iterating simple atomic operations /can/ produce strength.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
It's been lovely, but I have to scream now.
------------------------------
From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: Re: new/old encryption technique
Date: Thu, 16 Mar 2000 21:42:53 -0500
Reuben Sumner wrote:
> You have rediscovered the one time pad.
> Classically the one time pad consists of using a random bit string R and
> encrypting the message M by R XOR M. The security of this can be proven
> assuming that R is truly random and that the bits of R are never used more
> than once. This is a good scheme. The problem is that you need a way of
> generating a truly random R and securely transmitting R to the receiver. If
> you use a pseudo-random generator to create R in the first place then the
> cipher is still secure, albeit not provably. Be careful though, the notion
> of pseudo-randomness in cryptography is not the same as what your average C
> library rand() or random() routines use.
>
> Reuben
>
> Arthur Dardia wrote in message <[EMAIL PROTECTED]>...
> >I was sitting around just thinking and general and I came upon ROT-13.
> >My understanding is that each letter is replaced with one that is 13
> >letter's ahead of it - resulting in a rather weak cipher. However, what
> >if you generated a random number and broke it down into 2 digit groups.
> >Then, on the plaintext performed ROT-XX where XX is the first group,
> >succeedeed by another ROT-YY where YY is the second group, until you
> >reach the end of the random number. How secure is this, assuming you
> >have a good RNG?
Well gee...I feel stupid. :) This was a good learning experience.
Thanks to all those above who replied.
--
Arthur Dardia Wayne Hills High School [EMAIL PROTECTED]
PGP 6.5.1 Public Key http://www.webspan.net/~ahdiii/ahdiii.asc
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: my toy cipher
Date: Thu, 16 Mar 2000 18:29:38 -0000
The primary issue I see as it stands is with your key
schedule. You are subject to an attacker that succeeds in
isolating a single round. You are also subject to an
algebraic attack because your key schedule and encryption
unfold very easily. This gives an attacker the ability to
perform normal algebra on your cipher, something that is
typically quite devastating. I would suggest that you add a
permutation step between the rounds, depending on the forced
timing on this permutation (whether or not it can be
expressed as a simple function). By forcing an attacker to
do things in order, instead of allowing algebraic advances,
you can make it more difficult attack, while maintaining
close to the same speed quality. BTW it is a very nice first
attempt, or even a very nice beginning to a secure attempt,
and it's not often I say that (you can see my comments in
the Enigma thread if you'd like to know what I usually say,
although I was quite a bit more harsh than usual because he
has gone through several revisions). You may also want to
create at least one more round function, that would make
many attacks more difficult (see below). Just so you don't
think that this I am a final authority on it, no I am not
heavily published, my reputation does not extend world-wide,
and I only looked at your cipher for a few moments in making
my judgements, so I might be wrong.
Joe
My thoughts on the changes:
Your current (I'm posting here because it is small)
{
...
t = m[0]
m[0] = f()^m[1];
m[1] = t;
...
{
my suggestion is to make that
{
...
t = m[0]
m[0] = f()^m[1];
m[1] = f()^t;
t = m[0];
...
m[0] = g()^m[1];
m[1] = g()^t;
...
}
which should make it more robust. For g() you might consider
s-boxes, if they are well chosen they can be quite useful.
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: SALT with RC4, where do I store the SALT?
Date: Thu, 16 Mar 2000 22:14:54 -0500
On Thu, 16 Mar 2000 23:10:04 GMT, [EMAIL PROTECTED] (Impervious) wrote:
>On Thu, 16 Mar 2000 10:34:41 -0000, "Joseph Ashwood"
><[EMAIL PROTECTED]> wrote:
>
>Thanks for all the info guys, the only thing I'm fuzzy on is this:
>
>>In order to eliminate the attackable data more easily you
>>may want to pull a few hundred initial bytes out before
>>performing the encryption, 512 is a common (and fairly good)
>>number.
>
>I don't understand where to drop the bytes from.
Drop them from the stream, encrypt anything (random values, the letter
'X' or whatever) for 512 bytes and discard that output, then start
encrypting the plain text.
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
Subject: Re: Enigma encryption updated (Adam D)
From: stanislav shalunov <[EMAIL PROTECTED]>
Date: Fri, 17 Mar 2000 03:41:25 GMT
"Joseph Ashwood" <[EMAIL PROTECTED]> writes:
> (to encrypt a single byte b)
> For each character c in the password
> {
> b = (b+c) mod 256
> if b is odd
> b = b-1
> else
> b = b+1
> }
[...]
> The last if b is odd part is of no cryptographic value, so
> it can be eliminated easily.
Do you mean to say that this is as strong as:
(to encrypt a single byte b)
For each character c in the password
b = (b+c) mod 256
(Which is obviously a XOR with 1 byte key [sum of all bytes in the
original key mod 256].)
I don't see how it is so, and you mention 2 bytes of effective key
later. Could you explain what did you mean by the quoted statement?
------------------------------
From: [EMAIL PROTECTED] (Impervious)
Subject: Re: SALT with RC4, where do I store the SALT?
Date: Fri, 17 Mar 2000 03:48:41 GMT
On Thu, 16 Mar 2000 22:14:54 -0500, Johnny Bravo <[EMAIL PROTECTED]>
wrote:
Thanks guys... I get what you're saying now. :)
Manuel Alvarez
------------------------------
From: [EMAIL PROTECTED] (Nemo psj)
Subject: Re: Enigma encryption updated (Adam D)
Date: 17 Mar 2000 04:09:26 GMT
Hmm somehow I think you missed the entire word doc in your review of the algy
that's not how it encrypts at all also what you fail to realize is that after
passing the first byte through the wheels the password is thus passed through
the same wheels and whilst doing so encrypted with RC4 then the next byte is
thus encrypted (with the new pass which has just been generated). So to say
that it is simply XOR or that it is a simple substitution is completely
unjustified. If you still think your right go back to the word doc goto each
step I describe and see if that small thing you wrote down will cover it all I
really doubt it. Below is the RC4 method I used.
Note: I did tell exactly how RC4 is used in the algy i suggest you read the
word Doc again. =)
-Pure
Public Sub RC4ini(Pwd As String)
Dim temp As Integer, a As Integer, b As Integer
'Save Password in Byte-Array
b = 0
For a = 1 To 255
b = b + 1
If b > Len(Pwd) Then
b = 1
End If
kep(a) = Asc(Mid$(Pwd, b, 1))
Next a
'INI S-Box
For a = 1 To 255
s(a) = a
Next a
b = 0
For a = 1 To 255
b = (b + s(a) + kep(a)) Mod 255
' Swap( S(i),S(j) )
temp = s(a)
s(a) = s(b)
s(b) = temp
Next a
End Sub
Public Function EnDeCrypt(plaintxt As Variant) As Variant
Dim temp As Integer, a As Long, i As Integer, j As Integer, k As Integer
Dim cipherby As Byte, cipher As Variant
For a = 1 To Len(plaintxt)
i = (i + 1) Mod 255
j = (j + s(i)) Mod 255
' Swap( S(i),S(j) )
temp = s(i)
s(i) = s(j)
s(j) = temp
'Generate Keybyte k
k = s((s(i) + s(j)) Mod 255)
'Plaintextbyte xor Keybyte
cipherby = Asc(Mid$(plaintxt, a, 1)) Xor k
' Inserting fix for ch(0) bite
If Chr(cipherby) = Chr(0) Then
cipherby = 1
Else:
End If
cipher = cipher & Chr(cipherby)
Next a
EnDeCrypt = cipher
End Function
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Micro Stream Cipher
Date: Fri, 17 Mar 2000 04:03:54 GMT
I recently [for fun] wrote a micro-stream cipher, were I made a self-
shrinking generator out of a 55-word fibonacci generator. It's very
compact [requires under 60 bytes of ram] and reasonably efficient.
If anyone wants to check it out, or actually use it... [hey why not]
it's free for use. Just email me at [EMAIL PROTECTED]
This is most likely [with doubt] nothing new, but I saw some posters
looking for compact ciphers... well here ya are.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: SALT with RC4, where do I store the SALT?
Date: Thu, 16 Mar 2000 23:11:58 -0500
On Fri, 17 Mar 2000 03:48:41 GMT, [EMAIL PROTECTED] (Impervious) wrote:
>On Thu, 16 Mar 2000 22:14:54 -0500, Johnny Bravo <[EMAIL PROTECTED]>
>wrote:
>
>Thanks guys... I get what you're saying now. :)
>
>Manuel Alvarez
You're welcome, glad to have been of help.
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Fri, 17 Mar 2000 04:18:46 GMT
Jerry Coffin wrote:
> Almost undoubtedly. Unfortunately, "strictly conforming programs"
> and "useful programs" are pretty much disjoint subsets, so this
> doesn't really mean much.
Nearly all my C code is (usable as part of) a strictly conforming
program. That is good programming practice, as it enhances
portability. System-specific stuff can usually be isolated to a
few interface files.
------------------------------
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: Universal Language
Date: Thu, 16 Mar 2000 20:27:57 -0800
Vocative distinct from nominative exists in other Slavic languages and probably
existed in Old Church
Slavonic. It is not a speculative invention.
Richard Herring wrote:
> In article <8ap2t7$eic$[EMAIL PROTECTED]>, Mike McCarty
>([EMAIL PROTECTED]) wrote:
> > I might be the previous poster. The cases in Russian ar
>
> > nominative
> > genitive
> > dative
> > accusative
> > instrumental
> > prepositional
> > vocative
>
> > These are not all completely represented. IOW, in all cases there are
> > only masculine, feminine, neuter, and a common plural. The plurals for
> > these used to be distinct. Even given this, there are not 7x3 = 21 sets
> > of endings for either nouns or adjectives. There aren't even 6x3 = 18
> > sets (omitting the vocative).
>
> Are there *any* instances where the vocative can be distinguished
> from the nominative, or is it just a grammarians' invention?
>
> --
> Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: On jamming interception networks
Date: Fri, 17 Mar 2000 04:24:05 GMT
jungle wrote:
> > ... Hayden's speech to the Kennedy Political Union.
> how to get grip of this speech ? on internet, please ...
It should be on the NSA Web site.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Enigma encryption updated (Adam D)
Date: Thu, 16 Mar 2000 20:03:12 -0000
> (to encrypt a single byte b)
> For each character c in the password
> b = (b+c) mod 256
>
> (Which is obviously a XOR with 1 byte key [sum of all
bytes in the
> original key mod 256].)
That is what I was stating, the +/-1 can actually be pulled
out of the loop, and can from there be reversed. I wasn't
using it as XOR, I was using it as addition.
> I don't see how it is so, and you mention 2 bytes of
effective key
> later. Could you explain what did you mean by the quoted
statement?
Because all bytes of the key are used fro every encryption,
you can easily determine both of the values (the original
key, and the XORed value) in this case giving only 2-bytes
worth of protection.
Joe
------------------------------
Subject: Re: Universal Language
From: stanislav shalunov <[EMAIL PROTECTED]>
Date: Fri, 17 Mar 2000 04:58:37 GMT
[EMAIL PROTECTED] (Mike McCarty) writes:
> The cases in Russian ar
[...]
> vocative
In Russian vocative is defunct. There are three words that have it:
"Otche", "Bozhe", and "Gospodi" (all three happen to refer to God and
can be considered borrowings). Average educated native speaker
doesn't know anything about any "vocative."
No dictionary or grammar recognizes it.
------------------------------
Subject: Re: Enigma encryption updated (Adam D)
From: stanislav shalunov <[EMAIL PROTECTED]>
Date: Fri, 17 Mar 2000 05:04:21 GMT
"Joseph Ashwood" <[EMAIL PROTECTED]> writes:
> > (to encrypt a single byte b)
> > For each character c in the password
> > b = (b+c) mod 256
> I wasn't using it as XOR, I was using it as addition.
So, to encrypt a single byte b, we add to it the value of s mod 256,
where s is the sum of all bytes of key mod 256.
So, s is the key, and it's just 1 byte. Where does the other byte
come from?
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Enigma encryption updated (Adam D)
Date: Thu, 16 Mar 2000 21:07:13 -0000
The other byte comes from the chaining method being used
(which is keyed), and it's only an estimate, it might be off
by a few bits.
Joe
------------------------------
** 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
******************************
