8-bit hash function

[David Eather]

First TIA for your attention!

This is my first attempt at a hash function targeting 8-bit processors. I
am looking for comments, criticisms, etc (and suggestions for names – I
was thinking “Eric” but since that is the name of a grasshopper...).

The design is based on RC-4 minus any generation of output. The input is
an arbitrary number of bytes and length does not need to be specified.
The hash output is 256-bits and shorter outputs can be obtained by
truncation. It requires 300 bytes of RAM, which is indeed a bit high, but
it can still run on some ATTiny and mid range PIC’s with enough resources
left over for useful work. On a 16MHz ATMEGA (unoptimised C code)
initialisation and finalisation takes under 100 milliseconds and data is
processed at more than 64kbyes/sec. The hash should be fast very as the
underlying cipher is fast and the hash function does not produce an out
stream of bytes. After a finalisation process the s-Box state is used to
calculate the hash function. As per RC-4 all maths are performed Modulus
256

General Outline

1. Initialisation

Initialisation is the same as RC-4, all variables including the elements
of the hash array are zeroed and the s-Box entries are set to the identity
elements.

2. Data Input

The hash function is generally based on RC-4. Data to be hashed is feed
into the algorithm as what would be the key in RC-4. The differences are
that the data bytes are feed in regardless of length i.e. data streams
shorter than 256-bytes are not repeated or padded to make them 256-bytes
long. Long data streams are feed in without regard to length and also are
not padded or otherwise modified.

3. Finalisation

With the data input over the hash function iterates for 3-k (3072) cycles.
This iteration is identical to the RC-4 output function except that there
no output calculated. The 3072 cycles are the minimum required to remove
correlations in the output of RC-4 and the key. It is assumed it is also
sufficient to remove correlations between the s-Box state and the data
input.

4. Hash Calculation

Description of the hash calculation is best described by visualising the
256-byte s-box as a 16 x 16 array. The hash output is 32 checksum bytes
each of either a single row or single column.

5. Finish

All unnecessary data and variables is zeroed and returned to the system.


Not so great Pseudo code description

//Initialisation

i = 0
j = 0
for i = 0 to 31
h(i) = 0

for i = 0 to 255
s(i) = i


//Data Input

i = 0
j = 0
Do while Data available
i =i+1 Mod 256
j = (j + s(i) + Data) Mod 256
swap s(i), s(j)

// Finalisation

i = 0
j = 0
for n = 0 to 3071
i =i+1 Mod 256
j = (j + s(i) + Data) Mod 256
swap s(i), s(j)

//Hash Calculation

// h(0) to h(15)
for i = 0 to 15
for j = 0 to 15
h(i)= (h(i) + s(i * 16 + j) Mod 256

//h(16) to h(31)
for i = 0 to 15
for j = 0 to 15
h(i + 16) = ((h(i + 16) + s(i + j * 16)) Mod 256
hash = h(0) | h(1) | h(2) … h(31)


//5. Finish

i = 0
j = 0
for i = 0 to 31
h(i) = 0

for i = 0 to 255
s(i) = 0



Test vectors

Null input

OxDF6CD4CE0AE7D8FF66FF2D0FCF28033017E45090B33C441CD86F829935E66B6E

1 binary %00000001 input

Ox9BBBA28125FF2AD5A2C6C8BA249D67D23622D988999F9D6F6BE49A89F2712C82

1 million binary %00000001 inputs

Ox9DD1BA799AFE3DBE03BE72D52DBFEA6E5490F426D7C76E591951AF98AC839DA0


David Eather 10 April 2017
--
Using Opera's mail client: http://www.opera.com/mail/

[austin...@hotmail.com]

Good Luck with your work,

adacrypt

[Karl.Frank]

Your idea is a bit different than my approach with p8
(http://www.freecx.co.uk/crypto/p8/) because you use just one internal
state array as p8 uses two and also RC4 as core cipher algorithm instead
a home-brew one.

Interesting though that your pseudo code is more compact than mine.

Did you consider testing the output quality of you're hash function with
the SMhasher (https://github.com/rurban/smhasher) test suite?

I found it very helpful because the results quite quickly reveals if
there is bias in the output after running a bunch of different tests.



--
cHNiMUBACG0HAAAAAAAAAAAAAABIZVbDdKVM0w1kM9vxQHw+bkLxsY/Z0czY0uv8/Ks6WULxJVua
zjvpoYvtEwDVhP7RGTCBVlzZ+VBWPHg5rqmKWvtzsuVmMSDxAIS6Db6YhtzT+RStzoG9ForBcG8k
G97Q3Jml/aBun8Kyf+XOBHpl5gNW4YqhiM0=

[Karl.Frank]

One additional remark in regards of maintaining only one internal state
array in your algorithm:

due to my observation a second independently updated internal state
array ( key[] in my case ) was absolutely necessary because otherwise
the output hash never survived any of the SMhasher test runs properly.

Would be interesting to see how your algorithm cope with the test suite.

In general I am much in favour of such 8-bit byte swap hash functions
build around a substitution cipher as they offer a large range of
application apart from hashing - even as PBKDF ...

By the way, Peter Pearson's 8-bit hash function brought me on track.


--
cHNiMUBACG0HAAAAAAAAAAAAAABIZVbDdKVM0w1kM9vxQHw+bkLxsY/Z0czY0uv8/Ks6WULxJVua
zjvpoYvtEwDVhP7RGTCBVlzZ+VBWPHg5rqmKWvtzsuVmMSDxAIS6Db6YhtzT+RStzoG9ForBcG8k
G97Q3Jml/aBun8Kyf+XOBHpl5gNW4YqhiM0=

[austin...@hotmail.com]

On Monday, April 10, 2017 at 5:56:14 AM UTC+1, David Eather wrote:

What is a hash key - I may already have exploratory work on other things that are applicable to Hash key creation - too much in hand just to pursue hash key creation but I am always interested in new avenues such as your current hash key design best wishes - adacrypt

[MM]

On Tuesday, 11 April 2017 08:39:50 UTC+1, austin...@hotmail.com wrote:
> What is a hash key

https://en.wikipedia.org/wiki/Hash_function

M
--

[Peter Pearson]

Essential summary: A figure caption on that page uses "key" to refer to
a hash function's input. That is the only appearance of "key" on that
page.

In a cryptographic context, calling an input a "key" is misleading,
since the word carries so many associations (particularly of secrecy,
often of shared-ness) that do not usually apply to hash function inputs.

--
To email me, substitute nowhere->runbox, invalid->com.

[David Eather]

On Tue, 11 Apr 2017 09:39:09 +1000, Karl.Frank <Karl....@freecx.co.uk>
wrote:

> One additional remark in regards of maintaining only one internal state
> array in your algorithm:
>
> due to my observation a second independently updated internal state
> array ( key[] in my case ) was absolutely necessary because otherwise
> the output hash never survived any of the SMhasher test runs properly.
>
> Would be interesting to see how your algorithm cope with the test suite.
>
> In general I am much in favour of such 8-bit byte swap hash functions
> build around a substitution cipher as they offer a large range of
> application apart from hashing - even as PBKDF ...
>
> By the way, Peter Pearson's 8-bit hash function brought me on track.
>
>

Most (all?) hash functions only have one internal state so I don't know
what to say. I hadn't heard of smhasher at all. I'll see.

[David Eather]

>>
>>
>>
>> Test vectors
>>
>> Null input
>>
>> OxDF6CD4CE0AE7D8FF66FF2D0FCF28033017E45090B33C441CD86F829935E66B6E
>>
>> 1 binary %00000001 input
>>
>> Ox9BBBA28125FF2AD5A2C6C8BA249D67D23622D988999F9D6F6BE49A89F2712C82
>>
>> 1 million binary %00000001 inputs
>>
>> Ox9DD1BA799AFE3DBE03BE72D52DBFEA6E5490F426D7C76E591951AF98AC839DA0
>>
>>
>> David Eather 10 April 2017
>> --
>> Using Opera's mail client: http://www.opera.com/mail/
>
> What is a hash key - I may already have exploratory work on other things
> that are applicable to Hash key creation - too much in hand just to
> pursue hash key creation but I am always interested in new avenues such
> as your current hash key design best wishes - adacrypt

There is no such thing as a hash key. When data is feed in, the output of
the hash function is called a fingerprint (of the input file, by the
specified hash function). Test vectors are provided so you can write an
identical function in any language you choose. Of interest, see the first
two fingerprints, a single extra byte input causes about half of the
output bits to change - an essential property but if that is the only
property this hash function has than it is insufficient for it to be a
good hash function.

[Bruce Stephens]

On 11/04/2017 19:19, David Eather wrote:

> There is no such thing as a hash key. When data is feed in, the output
> of the hash function is called a fingerprint (of the input file, by the
> specified hash function). Test vectors are provided so you can write an
> identical function in any language you choose. Of interest, see the
> first two fingerprints, a single extra byte input causes about half of
> the output bits to change - an essential property but if that is the
> only property this hash function has than it is insufficient for it to
> be a good hash function.

It does seem that the term key is sometimes used for the input for
non-cryptographic hashes. Also it seems natural usage for MAC (indeed,
aren't MACs sometimes called keyed hashes?).

[Karl.Frank]

Your algorithm must be extremely fast, even by injecting one byte at
a time. It's intriguingly simple - I like that.

Interesting approach in calculation of the final hash, as it looks to me
that your focus is there.

So it might be that your algorithm really survive the smhasher tests.


--
cHNiMUBACG0HAAAAAAAAAAAAAABIZVbDdKVM0w1kM9vxQHw+bkLxsY/Z0czY0uv8/Ks6WULxJVua
zjvpoYvtEwDVhP7RGTCBVlzZ+VBWPHg5rqmKWvtzsuVmMSDxAIS6Db6YhtzT+RStzoG9ForBcG8k
G97Q3Jml/aBun8Kyf+XOBHpl5gNW4YqhiM0=

[Karl.Frank]

Just imagine that a secret key is passed in a Key Schedule Algorithm as
we know it from RC4 right after the Initialisation.

Now you would have a keyed internal state where you start with
calculating the final hash - therefore the algorithm of David would
produce a HMAC (keyed MAC).


--
cHNiMUBACG0HAAAAAAAAAAAAAABIZVbDdKVM0w1kM9vxQHw+bkLxsY/Z0czY0uv8/Ks6WULxJVua
zjvpoYvtEwDVhP7RGTCBVlzZ+VBWPHg5rqmKWvtzsuVmMSDxAIS6Db6YhtzT+RStzoG9ForBcG8k
G97Q3Jml/aBun8Kyf+XOBHpl5gNW4YqhiM0=

[David Eather]

MAC is not Hash

[David Eather]

On Wed, 12 Apr 2017 05:36:10 +1000, Bruce Stephens
<bruce.r....@gmail.com> wrote:

MAC is not Hash

[Karl.Frank]

But a hash is used for MAC, as I have explained earlier in regards of
extending your hash algorithm for generation of a HMAC.

--
cHNiMUBACG0HAAAAAAAAAAAAAABIZVbDdKVM0w1kM9vxQHw+bkLxsY/Z0czY0uv8/Ks6WULxJVua
zjvpoYvtEwDVhP7RGTCBVlzZ+VBWPHg5rqmKWvtzsuVmMSDxAIS6Db6YhtzT+RStzoG9ForBcG8k
G97Q3Jml/aBun8Kyf+XOBHpl5gNW4YqhiM0=

[David Eather]

On Tue, 11 Apr 2017 09:39:09 +1000, Karl.Frank <Karl....@freecx.co.uk>
wrote:

> One additional remark in regards of maintaining only one internal state
> array in your algorithm:
>
> due to my observation a second independently updated internal state
> array ( key[] in my case ) was absolutely necessary because otherwise
> the output hash never survived any of the SMhasher test runs properly.
>
> Would be interesting to see how your algorithm cope with the test suite.
>
> In general I am much in favour of such 8-bit byte swap hash functions
> build around a substitution cipher as they offer a large range of
> application apart from hashing - even as PBKDF ...
>
> By the way, Peter Pearson's 8-bit hash function brought me on track.
>
>

pearson's hash function is hideous (for a cryptographic hash - I have no
opinion for other uses)

[Karl.Frank]

It is not designed to be cryptographically secure. But essentially the
idea on *how* he designed it to *me* was the needed inspiration. Digging
further into how to implement a hash function based on a RC4-like
substitution cipher I came across the cryptanalysis of RC4-based hash
function https://core.ac.uk/display/19966118
http://minerva.mq.edu.au:8080/vital/access/manager/Repository/mq:24177

and the RC4-Hash
http://www.isical.ac.in/~mridul/Papers/Papers/Indo-06-RC4-hash.pdf
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.572.4085

But I don't like the concept of hashing the message in blocks, the
potential necessity of padding and the fact that the message data are
incorporated in a KSA like function. I prefer calling the KSA once and
thereafter adding the data to the internal state. The Pearson hash is
exactly using this method. As it seems more logical to me that's why I
adopted it to my p8 hash function, as you did with your algorithm.

But still I consider it potentially problematic if the final hash is
entirely based on the one internal state array only.

Especially it's unclear to me what kind of "Data" your algorithm injects
in the Finalisation function. Where do these 3071 Data byte origin from
when all available data are already injected in the Data Input function?


--
cHNiMUBACG0HAAAAAAAAAAAAAABIZVbDdKVM0w1kM9vxQHw+bkLxsY/Z0czY0uv8/Ks6WULxJVua
zjvpoYvtEwDVhP7RGTCBVlzZ+VBWPHg5rqmKWvtzsuVmMSDxAIS6Db6YhtzT+RStzoG9ForBcG8k
G97Q3Jml/aBun8Kyf+XOBHpl5gNW4YqhiM0=

[Peter Pearson]

On Sat, 15 Apr 2017 14:33:46 +1000, David Eather <eat...@tpg.com.au> wrote:
>
> pearson's hash function is hideous (for a cryptographic hash

[snip]

Absolutely right.

[Karl.Frank]

There is one question and a note I like to leave.

1) It's unclear to me what kind of "Data" your algorithm injects in the

Finalisation function. Where do these 3071 Data byte origin from when
all available data are already injected in the Data Input function?

(asked that already in a different answer)

2) Before the actual hash is calculated in the Hash Calculation function
you "freeze" the internal state array. I consider this problematic
because an attacker might find it easy reverse calculating the complete
internal state. This might help him crafting a second file that result
in the same hash. Especially as the whole data injection process is
relatively simple. Reverse calculation of the RC4 internal state is
already published.
http://www.cs.technion.ac.il/~yanivca/RC4StateReconstruction.pdf

You might consider something similar as the HBG (hash byte generation)
in RC4-Hash or like the on on p8 instead in your Hash Calculation
function were the internal state array is updated for every hash byte
output.
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.572.4085




--
cHNiMUBACG0HAAAAAAAAAAAAAABIZVbDdKVM0w1kM9vxQHw+bkLxsY/Z0czY0uv8/Ks6WULxJVua
zjvpoYvtEwDVhP7RGTCBVlzZ+VBWPHg5rqmKWvtzsuVmMSDxAIS6Db6YhtzT+RStzoG9ForBcG8k
G97Q3Jml/aBun8Kyf+XOBHpl5gNW4YqhiM0=

[David Eather]

On Sat, 15 Apr 2017 23:57:21 +1000, Karl.Frank <Karl....@freecx.co.uk>
wrote:

Almost all hash functions have only 1 internal state.

>
> Especially it's unclear to me what kind of "Data" your algorithm injects
> in the Finalisation function. Where do these 3071 Data byte origin from
> when all available data are already injected in the Data Input function?
>
>

3072 iterations. From a paper Not so random shuffles of RC4

https://eprint.iacr.org/2002/067.pdf


The purpose is to ensure there is no exploitable correlations between data
and the state. In my case it is to make calculating how to get a
predefined final state difficult.

[David Eather]

On Sat, 15 Apr 2017 23:57:21 +1000, Karl.Frank <Karl....@freecx.co.uk>
wrote:

Almost all hash functions have only 1 internal state.


>

> Especially it's unclear to me what kind of "Data" your algorithm injects
> in the Finalisation function. Where do these 3071 Data byte origin from
> when all available data are already injected in the Data Input function?
>
>

3072 iterations. From a paper Not so random shuffles of RC4

https://eprint.iacr.org/2002/067.pdf


The purpose is to ensure there is no exploitable correlations between data
and the state. In my case it is to make calculating how to get a
predefined final state difficult.

[David Eather]

On Sat, 15 Apr 2017 23:57:21 +1000, Karl.Frank <Karl....@freecx.co.uk>
wrote:

Almost all hash functions have only 1 internal state.


>

> Especially it's unclear to me what kind of "Data" your algorithm injects
> in the Finalisation function. Where do these 3071 Data byte origin from
> when all available data are already injected in the Data Input function?
>
>

3072 iterations. From a paper Not so random shuffles of RC4

https://eprint.iacr.org/2002/067.pdf


The purpose is to ensure there is no exploitable correlations between data
and the state. In my case it is to make calculating how to get a
predefined final state difficult.

[David Eather]

On Sat, 15 Apr 2017 23:57:21 +1000, Karl.Frank <Karl....@freecx.co.uk>
wrote:

Thanks for the references. I have a lot to go through, but my hash is
looking decidedly sick and may not make it :(


Also sorry to everyone for the ridiculous number of repeated sends - I
have no idea what is happening.

[Karl.Frank]

To my experience a hash function based on a non-linear substitution
lookup table maintaining only 1 internal state array does fail almost
all tests of the smhasher test battery.

I soon realised that a second internal state array does the trick.
That's why my algorithm p8 maintains two internal state arrays. The
first one is the internal state of the included stream cipher, the
second one is separately and additionally updated with every data byte
injected based on the value stored in an sbox element of the stream
ciphers internal state array. This way a huge 256byte "key" is formed
which is based on the data to hash as well as the fast changing internal
state array of the stream cipher.

Right after all data are processed a complete internal state of the
stream ciphers sbox array is dropped - somewhat similar as in your
finalisation function - followed by an update of the 256 sbox elements
of the second "key" array by the output of the stream cipher.

Finally the content of the second separate array is used as a 256byte
key which is passed over to the stream cipher's KSA and incorporated
into its internal state array before calculation of the final hash
values. This way a most unique internal state is generated based on the
data and the second "key" array. This seem adequate especially if the
data to hash is of low amount.

You're absolutely right about the danger of a potential predefined final
state, because no matter how many data byte were to process, the final
hash is calculated only of an unknown 256byte permutation, not that very
much in fact.

But in contrast to your scheme, were the internal state is fixed the
internal state of p8 is updated with every hash byte output at least.
Something you should consider to implement as well.

And your final hash calculation function make me re-think my own design,
because I realised that in my case only a fraction of the 256byte is
used for hash calculation, while in yours the whole internal state is
included in the final hash calculation. So your function with an
internal state update included might be far more secure than just a
fractional drawing from the internal state.


--
cHNiMUBACG0HAAAAAAAAAAAAAABIZVbDdKVM0w1kM9vxQHw+bkLxsY/Z0czY0uv8/Ks6WULxJVua
zjvpoYvtEwDVhP7RGTCBVlzZ+VBWPHg5rqmKWvtzsuVmMSDxAIS6Db6YhtzT+RStzoG9ForBcG8k
G97Q3Jml/aBun8Kyf+XOBHpl5gNW4YqhiM0=

[Karl.Frank]

You're welcome. Perhaps you might consider building your hash functions
around the stream cipher leaving its algorithm untouched.

> Also sorry to everyone for the ridiculous number of repeated sends - I
> have no idea what is happening.

It's happening to me also once in a while when the newsgroup server is
not responding immediately.


--
cHNiMUBACG0HAAAAAAAAAAAAAABIZVbDdKVM0w1kM9vxQHw+bkLxsY/Z0czY0uv8/Ks6WULxJVua
zjvpoYvtEwDVhP7RGTCBVlzZ+VBWPHg5rqmKWvtzsuVmMSDxAIS6Db6YhtzT+RStzoG9ForBcG8k
G97Q3Jml/aBun8Kyf+XOBHpl5gNW4YqhiM0=

[Karl.Frank]

On 15.04.17 22:04, David Eather wrote:

[...snip...]

>> Especially it's unclear to me what kind of "Data" your algorithm injects
>> in the Finalisation function. Where do these 3071 Data byte origin from
>> when all available data are already injected in the Data Input function?
>>

> The purpose is to ensure there is no exploitable correlations between data
> and the state. In my case it is to make calculating how to get a
> predefined final state difficult.
>

Just like to mention something in regards to the finalisation function.

In most cases of passing a cryptographic hash it comes alongside the
digital file that is the source of that particular hash. Let it be a
document, an image or an ISO, the attacker has both at hand.

This enables him tracing every single step of change of the internal
state while the algorithm is calculating the hash. Therefore he exactly
knows which byte of input data produce which swap and sbox value at any
time. So even dropping a 100,000 byte in the finalisation function will
only extend the time to follow up, nothing else.

The design of the data input function as you propose (actually just the
KSA of RC4 were "Data" replaces the key[]) might be a far too simple
construct. Even if it might be difficult crafting a second file that
result in the same final internal state, there is the risk that a file
that contains for example a lot of 0x0 might be an opportunity were the
attacker can inject his specially crafted data that will change the
final internal state in his favour. If you open any JPEG file with a hex
editor you find a lot of 0x0 right at the header.

In the light of this possibility I prefer a second internal state array
(key[]) which get updated alongside the internal state of the stream
cipher. The idea is to make it a more complex task for an attacker
injecting data in order to achieve a desired final state of the stream
cipher.


--
cHNiMUBACG0HAAAAAAAAAAAAAABIZVbDdKVM0w1kM9vxQHw+bkLxsY/Z0czY0uv8/Ks6WULxJVua
zjvpoYvtEwDVhP7RGTCBVlzZ+VBWPHg5rqmKWvtzsuVmMSDxAIS6Db6YhtzT+RStzoG9ForBcG8k
G97Q3Jml/aBun8Kyf+XOBHpl5gNW4YqhiM0=

[Karl.Frank]

Do you have any ANSI-C (or even BASIC) source code for download available?

I would like to verify the avalanche effect up to 128bit hashes of your
hash calculation function with SMHasher, but my ANSI-C implementation is
unable to get the same hash result as you posted as test vector for the
input of 0x00000001

echo "010000: 00 00 00 01" | xxd -r -s -0x10000 > rc4_input.bin
cat rc4_input.bin | ./rc4_DavidEather_hash
8F72EECFDD50CC1F7BAF341C98383D23

With an empty input though my implementation does generate the correct
result

echo -en "" | ./rc4_DavidEather_hash
DF6CD4CE0AE7D8FF66FF2D0FCF280330


Perhaps I have missed something or my implementation is erroneous?

http://paste.debian.net/928107/



--
cHNiMUBACG0HAAAAAAAAAAAAAABIZVbDdKVM0w1kM9vxQHw+bkLxsY/Z0czY0uv8/Ks6WULxJVua
zjvpoYvtEwDVhP7RGTCBVlzZ+VBWPHg5rqmKWvtzsuVmMSDxAIS6Db6YhtzT+RStzoG9ForBcG8k
G97Q3Jml/aBun8Kyf+XOBHpl5gNW4YqhiM0=

[MM]

On Monday, 17 April 2017 21:49:29 UTC+1, Karl.Frank wrote:
> echo "010000: 00 00 00 01" | xxd -r -s -0x10000 > rc4_input.bin

Try other-endianness:

echo "010000: 01 00 00 00" | xxd -r -s -0x10000 > rc4_input.bin

M
--

[austin...@hotmail.com]

> --
> Using Opera's mail client: http://www.opera.com/mail/

Hi David,

I know nothing about hash functions and would like to ask a question.
Compared with a cipher how many entities are involved in its use - just two or many, many? - how many?

The reason I ask is to repeat my assertion that unless the entities can establish a private number system then their task of obfuscating data tables by means of a hash function or whatever is virtually impossible. Clearly of course if there are many enties more than just two then customising a workable system becomes very difficult and is prone to attack becuase of so many people being involved.

No amount of clever algorithms such as you have presented recently will ever be sufficient while they are using the PUBLIC number system however.

It's the same old conundrum of Eve knowing what number system Alice is using and Alice being forced to try and outwit her with nothing else but intelligence on her side despite Eve being equally clever and having exactly the same computing power. Alice's task is impossible.

I'm projecting this onto hash functions? Is it applicable?

Good luck again.

Austin O'Byrne

[Bruce Stephens]

On 18/04/2017 09:11, austin...@hotmail.com wrote:

> I know nothing about hash functions and would like to ask a question.

https://en.wikipedia.org/wiki/Cryptographic_hash_function

[Richard Heathfield]

On 18/04/17 09:11, austin...@hotmail.com wrote:

<snip>

> It's the same old conundrum of Eve knowing what number system Alice
> is using and Alice being forced to try and outwit her with nothing
> else but intelligence on her side despite Eve being equally clever
> and having exactly the same computing power. Alice's task is
> impossible.

Translation: you have a crack for AES. There are now several routes to
your becoming a millionaire, at least one of which is perfectly legal
and morally sound.

Well done you.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[Karl.Frank]

Yeah, tried that already but unfortunately got this result

echo "010000: 01 00 00 00" | xxd -r -s -0x10000 | ./rc4_DavidEather_hash
549f42d2a6827e1ca6b60c779ef0e862

echo "010000: 01 00 00 00" | xxd -r -s -0x10000 > rc4_input.bin

cat rc4_input.bin | ./rc4_DavidEather_hash
549f42d2a6827e1ca6b60c779ef0e862

Did you succeed with a proper resulting hash?


--
cHNiMUBACG0HAAAAAAAAAAAAAABIZVbDdKVM0w1kM9vxQHw+bkLxsY/Z0czY0uv8/Ks6WULxJVua
zjvpoYvtEwDVhP7RGTCBVlzZ+VBWPHg5rqmKWvtzsuVmMSDxAIS6Db6YhtzT+RStzoG9ForBcG8k
G97Q3Jml/aBun8Kyf+XOBHpl5gNW4YqhiM0=

[austin...@hotmail.com]

Straight up ? Do you mean I should prepare a marketable item on Amazon or Ebay like say "Personalised Cryptography for Home Computers" - I would appreciate your honest opinion.

Austin

[Richard Heathfield]

On 18/04/17 12:43, austin...@hotmail.com wrote:
> On Tuesday, April 18, 2017 at 11:03:13 AM UTC+1, Richard Heathfield
> wrote:
>> On 18/04/17 09:11, austin...@hotmail.com wrote:
>>
>> <snip>
>>
>>> It's the same old conundrum of Eve knowing what number system
>>> Alice is using and Alice being forced to try and outwit her with
>>> nothing else but intelligence on her side despite Eve being
>>> equally clever and having exactly the same computing power.
>>> Alice's task is impossible.
>>
>> Translation: you have a crack for AES. There are now several routes
>> to your becoming a millionaire, at least one of which is perfectly
>> legal and morally sound.
>>
>> Well done you.
>

> Straight up ?

Your claim (cited above) is that it is impossible for Alice to encrypt a
plaintext (using the ordinary number system) in such a way that Eve
cannot crack the encryption. If you can prove this, then you have also
proved that AES is not secure, and it should not be difficult to
monetise that knowledge.

> Do you mean I should prepare a marketable item on Amazon or Ebay like
> say "Personalised Cryptography for Home Computers"

No, because if your claim is correct then you've /also/ proved that none
of your own cryptographic algorithms is secure.

> - I would appreciate your honest opinion.

My opinions are always honest.

[Bruce Stephens]

On 18/04/2017 14:40, Richard Heathfield wrote:

> No, because if your claim is correct then you've /also/ proved that none
> of your own cryptographic algorithms is secure.

And the One Time Pad.

[David Eather]

>
> I'm projecting this onto hash functions? Is it applicable?
>
> Good luck again.
>
> Austin O'Byrne

Hash functions are made public - they don't need any secret parameters.
They don't hide data for secret communications. Instead they are used to
make sure that the data sent (secret data or or public data) is received
without alterations be they accidental like noise on the communication
channel or a bad byte on a CD or deliberate alterations.

[David Eather]

On Tue, 18 Apr 2017 21:40:20 +1000, Karl.Frank <Karl....@freecx.co.uk>
wrote:

> On 17.04.17 23:15, MM wrote:
>> On Monday, 17 April 2017 21:49:29 UTC+1, Karl.Frank wrote:
>>> echo "010000: 00 00 00 01" | xxd -r -s -0x10000> rc4_input.bin
>>
>> Try other-endianness:
>>
>> echo "010000: 01 00 00 00" | xxd -r -s -0x10000> rc4_input.bin
>>
>> M
>
> Yeah, tried that already but unfortunately got this result
>
> echo "010000: 01 00 00 00" | xxd -r -s -0x10000 | ./rc4_DavidEather_hash
> 549f42d2a6827e1ca6b60c779ef0e862
>
> echo "010000: 01 00 00 00" | xxd -r -s -0x10000 > rc4_input.bin
> cat rc4_input.bin | ./rc4_DavidEather_hash
> 549f42d2a6827e1ca6b60c779ef0e862
>
> Did you succeed with a proper resulting hash?
>
>

looks like you tried using a 32-bit int and not an 8-bit byte?

[David Eather]

On Tue, 18 Apr 2017 21:40:20 +1000, Karl.Frank <Karl....@freecx.co.uk>
wrote:

> On 17.04.17 23:15, MM wrote:
>> On Monday, 17 April 2017 21:49:29 UTC+1, Karl.Frank wrote:
>>> echo "010000: 00 00 00 01" | xxd -r -s -0x10000> rc4_input.bin
>>
>> Try other-endianness:
>>
>> echo "010000: 01 00 00 00" | xxd -r -s -0x10000> rc4_input.bin
>>
>> M
>
> Yeah, tried that already but unfortunately got this result
>
> echo "010000: 01 00 00 00" | xxd -r -s -0x10000 | ./rc4_DavidEather_hash
> 549f42d2a6827e1ca6b60c779ef0e862
>
> echo "010000: 01 00 00 00" | xxd -r -s -0x10000 > rc4_input.bin
> cat rc4_input.bin | ./rc4_DavidEather_hash
> 549f42d2a6827e1ca6b60c779ef0e862
>
> Did you succeed with a proper resulting hash?
>
>

Doesn't matter though. My hash is seriously busted the same way as
described in this:

https://www.esat.kuleuven.be/cosic/publications/article-1133.pdf

Since it is easy to make the state of the s-box what you want, then you
can easily make 2 files that hash to the same value.

[austin...@hotmail.com]

Thanks - Austin

[Karl.Frank]

If have tried

echo -n $'\x01' | ./rc4_DavidEather_hash
fb40b54d191cf38234053d757afba891

and also a 1 byte file

cat rc4_input.bin | ./rc4_DavidEather_hash
fb40b54d191cf38234053d757afba891


while this give me

echo -n $'\x01' | md5sum
55a54008ad1ba589aa210d2629c1df41

cat rc4_input.bin | md5sum
55a54008ad1ba589aa210d2629c1df41


I'm quite unsure if my implementation or the test vector is wrong.



But under the assumption that my implementation might be correct I can
possibly lift your spirit a bit be letting you know you that your hash
calculation function does a good job regarding a quick SMHasher test run


--- Testing (8bit RC4 based Hash proposed by David Eather on sci.crpyt)

[[[ Avalanche Tests ]]]

Testing 32-bit keys -> 128-bit hashes, 300000 reps.......... worst
bias is 0.634000%
Testing 64-bit keys -> 128-bit hashes, 300000 reps.......... worst
bias is 0.690667%
Testing 128-bit keys -> 128-bit hashes, 300000 reps.......... worst
bias is 0.829333%

[[[ Keyset 'Cyclic' Tests ]]]

Keyset 'Cyclic' - 8 cycles of 16 bytes - 100000 keys
Testing collisions - Expected 0.00, actual 0.00 ( 0.00x)
Testing distribution - Worst bias is the 14-bit window at bit 94 - 0.435%

Keyset 'Cyclic' - 8 cycles of 17 bytes - 100000 keys
Testing collisions - Expected 0.00, actual 0.00 ( 0.00x)
Testing distribution - Worst bias is the 14-bit window at bit 50 - 0.482%

Keyset 'Cyclic' - 8 cycles of 18 bytes - 100000 keys
Testing collisions - Expected 0.00, actual 0.00 ( 0.00x)
Testing distribution - Worst bias is the 14-bit window at bit 126 - 0.370%

Keyset 'Cyclic' - 8 cycles of 19 bytes - 100000 keys
Testing collisions - Expected 0.00, actual 0.00 ( 0.00x)
Testing distribution - Worst bias is the 14-bit window at bit 111 - 0.428%

Keyset 'Cyclic' - 8 cycles of 20 bytes - 100000 keys
Testing collisions - Expected 0.00, actual 0.00 ( 0.00x)
Testing distribution - Worst bias is the 14-bit window at bit 54 - 0.450%





Obviously it fails other tests because of too narrow hash values.
Something that you surely can improve with the next version of your hash.


[[[ Keyset 'TwoBytes' Tests ]]]

Keyset 'TwoBytes' - up-to-12-byte keys, 18616785 total keys
Testing collisions - Expected 0.00, actual 87956.00
(172713214848000456005838176256.00x) !!!!!
Testing distribution - Worst bias is the 20-bit window at bit 104 - 0.073%

Keyset 'TwoBytes' - up-to-14-byte keys, 29612895 total keys
Testing collisions - Expected 0.00, actual 133880.00
(103901884736003557336778014720.00x) !!!!!
Testing distribution - Worst bias is the 20-bit window at bit 41 - 0.044%

Keyset 'TwoBytes' - up-to-16-byte keys, 44251425 total keys
Testing collisions - Expected 0.00, actual 194086.00
(67454222201695979857845944320.00x) !!!!!
Testing distribution - Worst bias is the 20-bit window at bit 41 - 0.029%

Keyset 'TwoBytes' - up-to-18-byte keys, 63052575 total keys
Testing collisions - Expected 0.00, actual 271337.00
(46448619593610389054839324672.00x) !!!!!
Testing distribution - Worst bias is the 20-bit window at bit 62 - 0.019%

*********FAIL*********

[[[ Keyset 'Text' Tests ]]]

Keyset 'Text' - keys of form "Foo[XXXX]Bar" - 14776336 keys
Testing collisions - Expected 0.00, actual 956.00
(2979846180073709129590374400.00x) !!!!!
Testing distribution - Worst bias is the 20-bit window at bit 97 - 0.034%

Keyset 'Text' - keys of form "FooBar[XXXX]" - 14776336 keys
Testing collisions - Expected 0.00, actual 1931.00
(6018915244479428193968717824.00x) !!!!!
Testing distribution - Worst bias is the 20-bit window at bit 55 - 0.025%

Keyset 'Text' - keys of form "[XXXX]FooBar" - 14776336 keys
Testing collisions - Expected 0.00, actual 0.00 ( 0.00x)
Testing distribution - Worst bias is the 20-bit window at bit 14 - 0.017%

*********FAIL*********

[[[ Keyset 'Zeroes' Tests ]]]

Keyset 'Zeroes' - 65536 keys
Testing collisions - Expected 0.00, actual 280.00
(44368448016777352055586381889536.00x) !!!!!
Testing distribution - Worst bias is the 13-bit window at bit 92 - 0.572%

*********FAIL*********





--
cHNiMUBACG0HAAAAAAAAAAAAAABIZVbDdKVM0w1kM9vxQHw+bkLxsY/Z0czY0uv8/Ks6WULxJVua
zjvpoYvtEwDVhP7RGTCBVlzZ+VBWPHg5rqmKWvtzsuVmMSDxAIS6Db6YhtzT+RStzoG9ForBcG8k
G97Q3Jml/aBun8Kyf+XOBHpl5gNW4YqhiM0=

[austin...@hotmail.com]

On Tuesday, April 18, 2017 at 7:32:20 PM UTC+1, David Eather wrote:
> >

Would it be a worthwhile conjecture to say that the set of data leaving Alice and the set of data arriving at Bob's end must each satisfy a common test otherwise there has been interference of some sort on the way.

If I find a suitable test I can call it a hash function ? Is this idea simplistic.

adacrypt

[Rich]

austin...@hotmail.com wrote:
> On Tuesday, April 18, 2017 at 7:32:20 PM UTC+1, David Eather wrote:
>> >
>> > I'm projecting this onto hash functions? Is it applicable?
>> >
>> > Good luck again.
>> >
>> > Austin O'Byrne
>>
>> Hash functions are made public - they don't need any secret
>> parameters. They don't hide data for secret communications.
>> Instead they are used to make sure that the data sent (secret data
>> or or public data) is received without alterations be they
>> accidental like noise on the communication channel or a bad byte on
>> a CD or deliberate alterations.
>

> Would it be a worthwhile conjecture to say that the set of data
> leaving Alice and the set of data arriving at Bob's end must each
> satisfy a common test otherwise there has been interference of some
> sort on the way.

In a very broad sense, yes.

> If I find a suitable test I can call it a hash function ?

No. There is more required to be called a hash function beyond just "a
test of a data set".

> Is this idea simplistic.

Yes.

[Bruce Stephens]

On 20/04/2017 00:49, austin...@hotmail.com wrote:

> Would it be a worthwhile conjecture to say that the set of data leaving Alice and the set of data arriving at Bob's end must each satisfy a common test otherwise there has been interference of some sort on the way.
>
> If I find a suitable test I can call it a hash function ? Is this idea simplistic.

Not really. wikipedia has reasonable descriptions of these things, so
use it.

https://en.wikipedia.org/wiki/Cryptographic_hash_function
https://en.wikipedia.org/wiki/Message_authentication_code
https://en.wikipedia.org/wiki/Authenticated_encryption

[Karl.Frank]

Exactly, something you should also improve with your next version.

Just as an example I hashed the following strings and printed the
internal state right after the data injection has finished. The hash is
an intermediate value without involving the finalisation function. As
you can see the intermediate hashes clearly reflect the one bit change
of the input data. The final hashes however are fine due to the
extensive byte swapping inside the finalisation function.

intermediate hash = c29232fdece7627817 57 cd7848e0a9cc
intermediate hash = c29231fdece7627817 58 cd7848e0a9cc

Clearly an adversary would follow the evolvement of the sboxes and check
the internal state before the run of the finalisation function. His task
then in would be crafting a 256 byte order that would reset the sboxes
to their initial state and then add whatever byte he like in order to
generate two identical hashes for different documents. Well, nothing
done in a minute, but a motivated hacker might write some kind of
program to automate this task.



echo -en "01000000000000000000000003000000000010" | ./rc4_DavidEather_hash

05:31:64:97:cb:00:36:6d:a5:de:0e:53:12:cc:18:49:
89:ca:8f:4f:93:d8:1e:65:9f:1d:35:80:0d:e8:5f:ae:
fe:13:a1:f4:48:9e:23:27:28:29:2a:2b:2c:2d:2e:2f:
30:01:32:33:34:1a:06:37:38:39:3a:3b:3c:3d:3e:3f:
40:41:42:43:44:45:46:47:24:0f:4a:4b:4c:4d:4e:21:
50:51:52:0b:54:55:56:57:58:59:5a:5b:5c:5d:5e:16:
60:61:62:63:02:17:66:67:68:69:6a:6b:6c:07:6e:6f:
70:71:72:73:74:75:76:77:78:79:7a:7b:7c:7d:7e:7f:
1b:81:82:83:84:85:86:87:88:10:8a:8b:8c:8d:8e:0c:
90:91:92:14:94:95:96:03:98:99:9a:9b:9c:9d:25:0a:
a0:22:a2:a3:a4:08:a6:a7:a8:a9:aa:ab:ac:ad:1f:af:
b0:b1:b2:b3:b4:b5:b6:b7:b8:b9:ba:bb:bc:bd:be:bf:
c0:c1:c2:c3:c4:c5:c6:c7:c8:c9:11:04:1c:cd:ce:cf:
d0:d1:d2:d3:d4:d5:d6:d7:15:d9:da:db:dc:dd:09:df:
e0:e1:e2:e3:e4:e5:e6:e7:19:e9:ea:eb:ec:ed:ee:ef:
f0:f1:f2:f3:26:f5:f6:f7:f8:f9:fa:fb:fc:fd:20:ff:

intermediate hash = c29232fdece762781757cd7848e0a9cc

final hash = 1717ff3f85fbc4d98f1ecbffac7b6376


echo -en "01000000000000000000000003000000000001" | ./rc4_DavidEather_hash

05:31:64:97:cb:00:36:6d:a5:de:0e:53:12:cc:18:49:
89:ca:8f:4f:93:d8:1e:65:9f:1d:35:80:0d:e8:5f:ae:
fe:13:a1:f4:48:9d:23:27:28:29:2a:2b:2c:2d:2e:2f:
30:01:32:33:34:1a:06:37:38:39:3a:3b:3c:3d:3e:3f:
40:41:42:43:44:45:46:47:24:0f:4a:4b:4c:4d:4e:21:
50:51:52:0b:54:55:56:57:58:59:5a:5b:5c:5d:5e:16:
60:61:62:63:02:17:66:67:68:69:6a:6b:6c:07:6e:6f:
70:71:72:73:74:75:76:77:78:79:7a:7b:7c:7d:7e:7f:
1b:81:82:83:84:85:86:87:88:10:8a:8b:8c:8d:8e:0c:
90:91:92:14:94:95:96:03:98:99:9a:9b:9c:25:9e:0a:
a0:22:a2:a3:a4:08:a6:a7:a8:a9:aa:ab:ac:ad:1f:af:
b0:b1:b2:b3:b4:b5:b6:b7:b8:b9:ba:bb:bc:bd:be:bf:
c0:c1:c2:c3:c4:c5:c6:c7:c8:c9:11:04:1c:cd:ce:cf:
d0:d1:d2:d3:d4:d5:d6:d7:15:d9:da:db:dc:dd:09:df:
e0:e1:e2:e3:e4:e5:e6:e7:19:e9:ea:eb:ec:ed:ee:ef:
f0:f1:f2:f3:26:f5:f6:f7:f8:f9:fa:fb:fc:fd:20:ff:

intermediate hash = c29231fdece762781758cd7848e0a9cc

final hash = 2595bb5e98327337b1ee50ca6640b5a5



My own design p8 act differently, as shown below. The intermediate
hashes look widely different due the fact that for every output byte of
the hash the internal state variables and the internal state of the
stream cipher get updated. Still the two internal states are nearly
identical. But there is a second 256 byte internal state array (key[])
which get updated with every input byte as well (- even in the current
version it has not enough influence).

intermediate hash = 5ce27139ddf9a3ff18feed8192eadddf
intermediate hash = 3c624ee80e10758974d7e343d6c6314d


Though even if my first versions of SBox8 and p8 are not ideal (the PIA
was broken by rich here in public) I suppose it worth that you might
take a look on the design in order to get some inspiration on how to
design your next version.

The important point in my opinion is that every input byte should
change a widespread of internal state variables and update the stream
ciphers internal state as much as possible without slowing down the
hashing process too much.

Still p8 does suffer somehow on the same problem with a specially
crafted 256 byte order that reset the internal state. But as the
involved stream cipher is more complex than RC4 and there is the
internal key[] array (internal state not listed here) which needed to be
reset as well it might raise the bar for an adversary. But there is
always room for design improvement though ...

In general I'm convinced that it's possible to design a
cryptographically secure hash based on an RC4-like stream cipher.


echo -en "01000000000000000000000003000000000010" | ./p8

c6:16:36:fb:12:65:e7:08:ce:d1:2b:bc:a9:f8:f4:11:
ad:7c:10:cd:09:60:0c:33:95:a2:89:1e:6f:43:52:ae:
8b:c7:56:5b:5d:9f:7d:f6:c3:e8:61:da:53:cc:45:be:
37:b0:29:58:1b:94:0d:86:ff:78:f1:6a:e3:5c:d5:4e:
20:40:b9:32:ab:24:9d:00:8f:d6:81:fa:73:ec:e4:de:
57:d0:49:c2:3b:b4:2d:a6:1f:98:9e:8a:03:90:f5:6e:
a7:74:d9:b5:cb:44:bd:79:af:28:a1:1a:93:ed:85:fe:
77:f0:69:e2:6b:d4:4d:87:3f:b8:31:aa:23:9c:15:8e:
07:80:f9:72:eb:64:dd:99:cf:48:c1:3a:b3:2c:a5:4a:
97:f2:c8:02:7b:25:6d:e6:5f:d8:51:ca:3c:ba:35:2e:
27:a0:19:92:0b:84:fd:76:ef:68:e1:5a:d3:4c:c5:3e:
b7:30:66:22:9b:14:8d:06:7f:ac:71:ea:63:dc:55:4f:
47:c0:39:b2:41:a4:1d:96:0f:88:01:7a:f3:6c:e5:5e:
d7:50:c9:42:bb:34:17:26:04:18:91:0a:83:fc:75:ee:
67:e0:59:d2:4b:c4:3d:b6:2f:a8:21:9a:13:8c:05:7e:
f7:70:e9:62:db:54:82:46:bf:38:b1:2a:a3:1c:df:0e:

intermediate hash = 5ce27139ddf9a3ff18feed8192eadddf

final hash = 12b5a0d9b02f4d8a11b7b859c522bcb9



echo -en "01000000000000000000000003000000000001" | ./p8

c6:16:36:fb:12:65:e7:08:ce:d1:2b:bc:a9:f8:f4:11:
ad:7c:10:cd:09:60:0c:33:95:a2:89:1e:6f:43:52:ae:
8b:c7:56:5b:fc:0a:7d:f6:c3:e8:61:da:53:cc:45:be:
37:b0:29:58:1b:94:0d:86:ff:78:f1:6a:e3:5c:d5:4e:
20:40:b9:32:ab:24:9d:00:8f:d6:81:fa:73:ec:e4:de:
57:d0:49:c2:3b:b4:2d:a6:1f:98:9e:8a:03:90:f5:6e:
5d:74:d9:b5:cb:44:bd:79:af:28:a1:1a:93:ed:85:fe:
77:f0:69:e2:6b:d4:4d:87:3f:b8:31:aa:23:9c:15:8e:
07:80:f9:72:eb:64:dd:99:cf:48:c1:3a:b3:2c:a5:4a:
97:f2:c8:02:7b:25:6d:e6:5f:d8:51:ca:3c:ba:35:2e:
27:a0:19:92:0b:84:fd:76:ef:68:e1:5a:d3:4c:c5:3e:
b7:30:66:22:9b:14:8d:06:7f:ac:71:ea:63:dc:55:4f:
47:c0:39:b2:41:a4:1d:96:0f:88:01:7a:f3:6c:e5:5e:
d7:50:c9:42:bb:34:17:26:9f:18:91:04:83:a7:75:ee:
67:e0:59:d2:4b:c4:3d:b6:2f:a8:21:9a:13:8c:05:7e:
f7:70:e9:62:db:54:82:46:bf:38:b1:2a:a3:1c:df:0e:

intermediate hash = 3c624ee80e10758974d7e343d6c6314d

final hash = f99a21808c1d081aa57f1180753d2f75



--
cHNiMUBACG0HAAAAAAAAAAAAAABIZVbDdKVM0w1kM9vxQHw+bkLxsY/Z0czY0uv8/Ks6WULxJVua
zjvpoYvtEwDVhP7RGTCBVlzZ+VBWPHg5rqmKWvtzsuVmMSDxAIS6Db6YhtzT+RStzoG9ForBcG8k
G97Q3Jml/aBun8Kyf+XOBHpl5gNW4YqhiM0=

[Gordon Burditt]

> Would it be a worthwhile conjecture to say that the set of data
> leaving Alice and the set of data arriving at Bob's end must each
> satisfy a common test otherwise there has been interference of some
> sort on the way.

> If I find a suitable test I can call it a hash function ? Is this idea simplistic.

A hash function takes a variable number of bytes and generates a
fixed-length result. In typical use the message and the hash would
be transmitted together, so you transmit msg and hash(msg). If,
on reception, hash(msg) does not equal the received hash, something
went wrong. A hash function cannot guarantee to detect all errors (note
that the received hash might have errors in it, as it's transmitted
with the message).

A good hash function has a high probability of changing value for
the common types of errors that can be introduced into a message.
The types of errors are often caused by noise (in, say, radio
transmission), not malicious attacks.

Here, it is easy for Eve to alter the message and have it pass the
hash check, since hash() is a public function and it has no unknown
parameters. Eve alters the message any way she wants, replaces the
hash sent with hash(modified msg), and passes on modified_msg and its
hash to Bob.

It is fairly easy to prove that if the hash function is shorter than the
message, there will be more than one message with the same hash (since there
are more possible messages than possible hashes, there *HAVE* to be
collisions), so not all errors can be detected.

Hash functions by themselves do not provide secrecy.


Here's a very simple hash function:
for a message consisting of N bytes, add the bytes, take
the result modulo 256, and the result is a 1-byte hash.
(Some implementations might take the negative of the result,
so the sum of all bytes including the hash modulo 256 should
be 0). This is called a checksum.

This was actually used in "Intel Hex" object code format
for small (e.g. 8-bit) microprocessors, where the bytes
were then turned into 2 ASCII hex digits before storing
them (sometimes on paper tape).

The job of this checksum was to detect accidental errors
in reading paper tape or transmitting it over a serial line
to load code into a processor. It is not hard to determine
that it will detect any single bit error in a record. Two
bit errors in the same record might cancel each other out
in their effect on the checksum. Swapping 2 bytes will not
be detected. Due to the way the code detected record
boundaries, and lax checking in boot loaders, it was possible
for an entire record to go missing without raising an error.

It would be pretty easy for Eve to figure out a message
that has the same checksum as what Alice sent. Making
it look real might be a little harder.

Here's a very, very simple (and *VERY* lame) hash function:
for a message consisting of N bytes, the hash is its length
N. This detects pretty much NO bit errors, only loss or
gain of bytes in the message.

Another one which Austin will like:
for a message consisting of N decimal digits, the hash is
computed as the sum of the odd digits plus twice the sum
of the digits of even digits, modulo 10. Some might recognize
this as similar to the Luhn checksum used for credit card
numbers (and if I'd bothered with the details, it would be
the same, but those aren't important here). It detects all
single-digit errors, and almost all swaps of two adjacent
digits (09 <--> 90) is not detected.

It's still really easy for Eve to come up with a fake message
that passes the checksum. Worst case, she needs only 10
guesses.

Internet IP header packets have a checksum consisting of the 1's complement
of the 1's complement sum of all the 16-bit words in the packet header.
This protects against single-bit transmission errors but
it provides no protection against deliberate alteration for things
such as Network Address Translation.

A CRC makes it a little bit harder to come up with a message that has the same CRC
as another message, and a CRC is better at detecting bursts
of errors. However, Eve doesn't *have* to come up with a
message with the same CRC if she can just replace the CRC
with her own.

An error-correcting code can be used to correct a limited number of bit errors in
the (message + hash) combination. This generally requires longer hashes
than ones that just detect errors. It is still trivial to replace a
real message with a fake one.

A cryptographic hash has the properties that the same message always
yields the same hash, computing the hash for a message is relatively
fast, it is infeasable to produce a message from its hash except
for trying all possible messages, a small change in a message makes
a large change in the hash, and it is infeasable to find two messages
with the same hash.

A cryptographic hash still doesn't prevent Eve from changing
the message, as the hash is still transmitted with the
message. However, if the message hash is *PUBLISHED* (e.g.
in the New York Times, so if Eve wants to change the message
she also has to change all copies of the day's New York
Times, or at least all the copies Bob might read), now Eve
is stuck with trying to find a message she wants to replace
the real one with that has the same cryptographic hash.
This is difficult.

You can use a hash function with a secret key. Sometimes this is done by computing
hash(secret || message), where || indicates concatenation,
and the secret is *NOT* transmitted along with the message
and hash. The hash can only be checked by someone who knows
the secret. In combination with a cryptographic hash, this
makes it very difficult for Eve to compute a correct hash
for her fake messages.

Other possibilities arise by combining encryption with hashing. If you send the message
encrypted but send the hash of the unencrypted message, it's harder for Eve
to generate correct hashes. But watch out that the hash of the unencrypted
message doesn't make it easier for Eve to crack the encryption. You are giving
her information about the plaintext.

[austin...@hotmail.com]

Thanks Gordon - I have something to work on now - I have perfected theoretically unbreakable cryptography - at least one instance of it and I am searching for an application to spatial hash functions - Many thanks

adacrypt

[MM]

On Saturday, 22 April 2017 09:51:18 UTC+1, austin...@hotmail.com wrote:
> I have perfected theoretically unbreakable cryptography

So why aren't you fabulously wealthy and incredibly famous?

Surely a bunch of contemptuous fools in sci.crypt can't be holding you
back with such a monumental discovery?

M
--

[Karl.Frank]

On 22.04.17 10:51, austin...@hotmail.com wrote:

> Thanks Gordon - I have something to work on now - I have perfected
> theoretically unbreakable cryptography - at least one instance of it
> and I am searching for an application to spatial hash functions -
> Many thanks
>
> adacrypt

Every encryption can be broken, apart from the One-Time-Pad. It's only a
question of effort, time and cost.

And yours has been broken frequently in public - enjoy your crypto la-la
land :-)


--
cHNiMUBACG0HAAAAAAAAAAAAAABIZVbDdKVM0w1kM9vxQHw+bkLxsY/Z0czY0uv8/Ks6WULxJVua
zjvpoYvtEwDVhP7RGTCBVlzZ+VBWPHg5rqmKWvtzsuVmMSDxAIS6Db6YhtzT+RStzoG9ForBcG8k
G97Q3Jml/aBun8Kyf+XOBHpl5gNW4YqhiM0=

[David Eather]

>
> Thanks Gordon - I have something to work on now - I have perfected
> theoretically unbreakable cryptography - at least one instance of it and
> I am searching for an application to spatial hash functions - Many thanks
>
> adacrypt

Austin,

You are not up to it. You just don't have the skills or understanding. All
you will do is waste your time. You must have something better to do.