Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > sci.crypt > #50099 > unrolled thread

CHAL2X

Back to article view | Back to sci.crypt

Contents

  CHAL2X Richard Heathfield <rjh@cpax.org.uk> - 2021-09-23 16:34 +0100
    Re: CHAL2X Max <maxturv26@gmx.net> - 2021-09-25 19:45 +0200
      Re: CHAL2X Richard Heathfield <rjh@cpax.org.uk> - 2021-09-25 19:04 +0100
        Re: CHAL2X Max <maxturv26@gmx.net> - 2021-09-25 20:08 +0200
    Re: CHAL2X Max <maxturv26@gmx.net> - 2021-09-25 23:03 +0200
      Re: CHAL2X Richard Heathfield <rjh@cpax.org.uk> - 2021-09-25 22:14 +0100
        Re: CHAL2X Max <maxturv26@gmx.net> - 2021-09-26 00:53 +0200
          Re: CHAL2X Richard Heathfield <rjh@cpax.org.uk> - 2021-09-26 06:59 +0100
            Re: CHAL2X Max <maxturv26@gmx.net> - 2021-09-26 14:40 +0200
              Re: CHAL2X Richard Heathfield <rjh@cpax.org.uk> - 2021-09-26 13:58 +0100
                Re: CHAL2X Max <maxturv26@gmx.net> - 2021-09-26 15:54 +0200
                  Re: CHAL2X Richard Heathfield <rjh@cpax.org.uk> - 2021-09-26 15:06 +0100
                    Re: CHAL2X Max <maxturv26@gmx.net> - 2021-09-26 17:11 +0200
                      Re: CHAL2X Richard Heathfield <rjh@cpax.org.uk> - 2021-09-26 16:53 +0100
                        Re: CHAL2X Richard Heathfield <rjh@cpax.org.uk> - 2021-09-26 17:12 +0100
                        Re: CHAL2X Max <maxturv26@gmx.net> - 2021-09-26 18:42 +0200
                          Re: CHAL2X Richard Heathfield <rjh@cpax.org.uk> - 2021-09-26 18:27 +0100
                            Re: CHAL2X Max <maxturv26@gmx.net> - 2021-09-26 20:43 +0200
                              Re: CHAL2X Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-26 20:41 +0100
                                Re: CHAL2X Max <maxturv26@gmx.net> - 2021-09-26 21:46 +0200
                                Re: CHAL2X Richard Heathfield <rjh@cpax.org.uk> - 2021-09-26 20:57 +0100
                                  Re: CHAL2X Stefan Claas <spam.trap.usenet@gmail.com> - 2021-09-26 13:19 -0700
                                    Re: CHAL2X Max <maxturv26@gmx.net> - 2021-09-26 22:30 +0200
                                      Re: CHAL2X Richard Heathfield <rjh@cpax.org.uk> - 2021-09-26 21:37 +0100
                                    Re: CHAL2X Richard Heathfield <rjh@cpax.org.uk> - 2021-09-26 21:33 +0100
                                      Re: CHAL2X Stefan Claas <spam.trap.usenet@gmail.com> - 2021-09-26 13:39 -0700
                              Re: CHAL2X Richard Heathfield <rjh@cpax.org.uk> - 2021-09-26 20:53 +0100
                    Re: CHAL2X Colin <a@b.com> - 2021-09-27 19:11 +1300
                      Re: CHAL2X Richard Heathfield <rjh@cpax.org.uk> - 2021-09-27 07:41 +0100
                        Re: CHAL2X Colin <a@b.com> - 2021-09-27 20:02 +1300
                          Re: CHAL2X Richard Heathfield <rjh@cpax.org.uk> - 2021-09-27 08:27 +0100
                      Re: CHAL2X Colin <a@b.com> - 2021-09-28 20:09 +1300

Page 1 of 2  [1] 2  Next page →

#50099 — CHAL2X

It is not enough to solve this!

To win, you must be the first to explain the *whole* (very simple) 
algorithm. The full Monty, please. How, *precisely* have I encrypted 
this text?

  74 59 79 39 59 4A 7A 68 09 7B 7A 6D 7A 38 79 30
  7A 39 09 08 18 51 31 69 09 08 23 2E 1B 54 69 31
  7A 6D 7A 49 51 31 50 7A 49 79 29 59 7A 39 09 08
  39 48 51 31 69 09 08 2E 0D 18 7A 50 68 59 31 59
  7A 49 09 31 50 7A 31 50 30 79 08 19 59 7A 59 10
  59 08 50 31 0A 2E 6C 59 30 59 1B 31 7A 59 69 19
  68 50 7A 50 68 79 50 7A 49 51 31 50 7A 50 79 29
  59 7A 68 79 08 58 31 2E 54 09 7A 28 09 69 08 7A
  69 08 7A 6C 61 49 59 08 1B 31 7A 38 79 08 58 31
  4A 2E 6D 18 7A 50 30 51 50 68 7A 68 09 48 58 31
  7A 50 30 51 59 7A 39 09 08 50 59 08 50 31 0A 2E
  65 09 51 7A 79 08 58 7A 61 09 51 7A 08 09 7A 39
  30 09 31 31 7A 31 68 79 48 48 7A 70 79 30 50 23
  2E 65 09 51 7A 79 08 58 7A 61 09 51 7A 79 30 59
  7A 68 59 79 30 50 7A 69 08 7A 68 59 79 30 50 23
  2E 65 09 51 7A 50 09 7A 68 69 31 7A 48 09 10 59
  7A 49 51 31 50 7A 79 39 39 09 30 58 4A 2E 0D 30
  7A 68 79 10 59 7A 79 7A 11 09 49 79 08 7A 50 09
  7A 61 09 51 30 7A 48 09 30 58 23 2E 65 09 51 7A
  79 08 58 7A 61 09 51 7A 79 30 59 7A 31 51 30 59
  7A 50 09 19 59 50 68 59 30 4A 2E 7D 31 7A 50 68
  59 7A 11 69 08 50 59 30 7A 50 09 7A 18 09 51 48
  7A 11 59 79 50 68 59 30 0A 2E 15 68 69 48 59 31
  7A 79 7A 11 59 58 48 09 39 29 4B 68 61 49 08 7A
  11 59 7A 31 69 08 19 4A 2E 1C 59 59 58 7A 61 09
  51 30 31 59 48 10 59 31 7A 11 69 50 68 7A 71 51
  59 31 50 69 09 08 69 08 19 4A 2E 54 68 79 50 7A
  30 59 79 31 09 08 7A 11 09 08 58 59 30 7A 49 79
  61 7A 58 69 49 69 08 69 31 68 4A 2E 6C 09 11 7A
  50 68 51 31 7A 11 59 7A 49 59 50 4A 7A 79 08 58
  7A 50 68 59 31 59 7A 50 68 69 08 19 31 7A 18 69
  08 69 31 68 0A 2E

-- 
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

[toc] | [next] | [standalone]

#50126

On 23.09.21 17:34, Richard Heathfield wrote:
> It is not enough to solve this!
> 
> To win, you must be the first to explain the *whole* (very simple) 
> algorithm. The full Monty, please. How, *precisely* have I encrypted 
> this text?
> 
>   74 59 79 39 59 4A 7A 68 09 7B 7A 6D 7A 38 79 30
>   7A 39 09 08 18 51 31 69 09 08 23 2E 1B 54 69 31
>   7A 6D 7A 49 51 31 50 7A 49 79 29 59 7A 39 09 08
>   39 48 51 31 69 09 08 2E 0D 18 7A 50 68 59 31 59
>   7A 49 09 31 50 7A 31 50 30 79 08 19 59 7A 59 10
>   59 08 50 31 0A 2E 6C 59 30 59 1B 31 7A 59 69 19
>   68 50 7A 50 68 79 50 7A 49 51 31 50 7A 50 79 29
>   59 7A 68 79 08 58 31 2E 54 09 7A 28 09 69 08 7A
>   69 08 7A 6C 61 49 59 08 1B 31 7A 38 79 08 58 31
>   4A 2E 6D 18 7A 50 30 51 50 68 7A 68 09 48 58 31
>   7A 50 30 51 59 7A 39 09 08 50 59 08 50 31 0A 2E
>   65 09 51 7A 79 08 58 7A 61 09 51 7A 08 09 7A 39
>   30 09 31 31 7A 31 68 79 48 48 7A 70 79 30 50 23
>   2E 65 09 51 7A 79 08 58 7A 61 09 51 7A 79 30 59
>   7A 68 59 79 30 50 7A 69 08 7A 68 59 79 30 50 23
>   2E 65 09 51 7A 50 09 7A 68 69 31 7A 48 09 10 59
>   7A 49 51 31 50 7A 79 39 39 09 30 58 4A 2E 0D 30
>   7A 68 79 10 59 7A 79 7A 11 09 49 79 08 7A 50 09
>   7A 61 09 51 30 7A 48 09 30 58 23 2E 65 09 51 7A
>   79 08 58 7A 61 09 51 7A 79 30 59 7A 31 51 30 59
>   7A 50 09 19 59 50 68 59 30 4A 2E 7D 31 7A 50 68
>   59 7A 11 69 08 50 59 30 7A 50 09 7A 18 09 51 48
>   7A 11 59 79 50 68 59 30 0A 2E 15 68 69 48 59 31
>   7A 79 7A 11 59 58 48 09 39 29 4B 68 61 49 08 7A
>   11 59 7A 31 69 08 19 4A 2E 1C 59 59 58 7A 61 09
>   51 30 31 59 48 10 59 31 7A 11 69 50 68 7A 71 51
>   59 31 50 69 09 08 69 08 19 4A 2E 54 68 79 50 7A
>   30 59 79 31 09 08 7A 11 09 08 58 59 30 7A 49 79
>   61 7A 58 69 49 69 08 69 31 68 4A 2E 6C 09 11 7A
>   50 68 51 31 7A 11 59 7A 49 59 50 4A 7A 79 08 58
>   7A 50 68 59 31 59 7A 50 68 69 08 19 31 7A 18 69
>   08 69 31 68 0A 2E
> 


As you like it.

[toc] | [prev] | [next] | [standalone]

#50127

On 25/09/2021 18:45, Max wrote:
> On 23.09.21 17:34, Richard Heathfield wrote:
>> It is not enough to solve this!
>>
>> To win, you must be the first to explain the *whole* (very simple) 
>> algorithm. The full Monty, please. How, *precisely* have I encrypted 
>> this text?
>>
>>   74 59 79 39 59 4A 7A 68 09 7B 7A 6D 7A 38 79 30
>>   7A 39 09 08 18 51 31 69 09 08 23 2E 1B 54 69 31
>>   7A 6D 7A 49 51 31 50 7A 49 79 29 59 7A 39 09 08
>>   39 48 51 31 69 09 08 2E 0D 18 7A 50 68 59 31 59
>>   7A 49 09 31 50 7A 31 50 30 79 08 19 59 7A 59 10
>>   59 08 50 31 0A 2E 6C 59 30 59 1B 31 7A 59 69 19
>>   68 50 7A 50 68 79 50 7A 49 51 31 50 7A 50 79 29
>>   59 7A 68 79 08 58 31 2E 54 09 7A 28 09 69 08 7A
>>   69 08 7A 6C 61 49 59 08 1B 31 7A 38 79 08 58 31
>>   4A 2E 6D 18 7A 50 30 51 50 68 7A 68 09 48 58 31
>>   7A 50 30 51 59 7A 39 09 08 50 59 08 50 31 0A 2E
>>   65 09 51 7A 79 08 58 7A 61 09 51 7A 08 09 7A 39
>>   30 09 31 31 7A 31 68 79 48 48 7A 70 79 30 50 23
>>   2E 65 09 51 7A 79 08 58 7A 61 09 51 7A 79 30 59
>>   7A 68 59 79 30 50 7A 69 08 7A 68 59 79 30 50 23
>>   2E 65 09 51 7A 50 09 7A 68 69 31 7A 48 09 10 59
>>   7A 49 51 31 50 7A 79 39 39 09 30 58 4A 2E 0D 30
>>   7A 68 79 10 59 7A 79 7A 11 09 49 79 08 7A 50 09
>>   7A 61 09 51 30 7A 48 09 30 58 23 2E 65 09 51 7A
>>   79 08 58 7A 61 09 51 7A 79 30 59 7A 31 51 30 59
>>   7A 50 09 19 59 50 68 59 30 4A 2E 7D 31 7A 50 68
>>   59 7A 11 69 08 50 59 30 7A 50 09 7A 18 09 51 48
>>   7A 11 59 79 50 68 59 30 0A 2E 15 68 69 48 59 31
>>   7A 79 7A 11 59 58 48 09 39 29 4B 68 61 49 08 7A
>>   11 59 7A 31 69 08 19 4A 2E 1C 59 59 58 7A 61 09
>>   51 30 31 59 48 10 59 31 7A 11 69 50 68 7A 71 51
>>   59 31 50 69 09 08 69 08 19 4A 2E 54 68 79 50 7A
>>   30 59 79 31 09 08 7A 11 09 08 58 59 30 7A 49 79
>>   61 7A 58 69 49 69 08 69 31 68 4A 2E 6C 09 11 7A
>>   50 68 51 31 7A 11 59 7A 49 59 50 4A 7A 79 08 58
>>   7A 50 68 59 31 59 7A 50 68 69 08 19 31 7A 18 69
>>   08 69 31 68 0A 2E
>>
> 
> 
> As you like it.

Well done! But that just wins you the Top Eve prize (again). It 
*doesn't* tell me my algorithm. How did I do the mapping? Not: "Show me 
the map" which you can obviously do, but "Explain the mapping".

-- 
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

[toc] | [prev] | [next] | [standalone]

#50128

On 25.09.21 20:04, Richard Heathfield wrote:
> On 25/09/2021 18:45, Max wrote:
>> On 23.09.21 17:34, Richard Heathfield wrote:
>>> It is not enough to solve this!
>>>
>>> To win, you must be the first to explain the *whole* (very simple) 
>>> algorithm. The full Monty, please. How, *precisely* have I encrypted 
>>> this text?
>>>
>>>   74 59 79 39 59 4A 7A 68 09 7B 7A 6D 7A 38 79 30
>>>   7A 39 09 08 18 51 31 69 09 08 23 2E 1B 54 69 31
>>>   7A 6D 7A 49 51 31 50 7A 49 79 29 59 7A 39 09 08
>>>   39 48 51 31 69 09 08 2E 0D 18 7A 50 68 59 31 59
>>>   7A 49 09 31 50 7A 31 50 30 79 08 19 59 7A 59 10
>>>   59 08 50 31 0A 2E 6C 59 30 59 1B 31 7A 59 69 19
>>>   68 50 7A 50 68 79 50 7A 49 51 31 50 7A 50 79 29
>>>   59 7A 68 79 08 58 31 2E 54 09 7A 28 09 69 08 7A
>>>   69 08 7A 6C 61 49 59 08 1B 31 7A 38 79 08 58 31
>>>   4A 2E 6D 18 7A 50 30 51 50 68 7A 68 09 48 58 31
>>>   7A 50 30 51 59 7A 39 09 08 50 59 08 50 31 0A 2E
>>>   65 09 51 7A 79 08 58 7A 61 09 51 7A 08 09 7A 39
>>>   30 09 31 31 7A 31 68 79 48 48 7A 70 79 30 50 23
>>>   2E 65 09 51 7A 79 08 58 7A 61 09 51 7A 79 30 59
>>>   7A 68 59 79 30 50 7A 69 08 7A 68 59 79 30 50 23
>>>   2E 65 09 51 7A 50 09 7A 68 69 31 7A 48 09 10 59
>>>   7A 49 51 31 50 7A 79 39 39 09 30 58 4A 2E 0D 30
>>>   7A 68 79 10 59 7A 79 7A 11 09 49 79 08 7A 50 09
>>>   7A 61 09 51 30 7A 48 09 30 58 23 2E 65 09 51 7A
>>>   79 08 58 7A 61 09 51 7A 79 30 59 7A 31 51 30 59
>>>   7A 50 09 19 59 50 68 59 30 4A 2E 7D 31 7A 50 68
>>>   59 7A 11 69 08 50 59 30 7A 50 09 7A 18 09 51 48
>>>   7A 11 59 79 50 68 59 30 0A 2E 15 68 69 48 59 31
>>>   7A 79 7A 11 59 58 48 09 39 29 4B 68 61 49 08 7A
>>>   11 59 7A 31 69 08 19 4A 2E 1C 59 59 58 7A 61 09
>>>   51 30 31 59 48 10 59 31 7A 11 69 50 68 7A 71 51
>>>   59 31 50 69 09 08 69 08 19 4A 2E 54 68 79 50 7A
>>>   30 59 79 31 09 08 7A 11 09 08 58 59 30 7A 49 79
>>>   61 7A 58 69 49 69 08 69 31 68 4A 2E 6C 09 11 7A
>>>   50 68 51 31 7A 11 59 7A 49 59 50 4A 7A 79 08 58
>>>   7A 50 68 59 31 59 7A 50 68 69 08 19 31 7A 18 69
>>>   08 69 31 68 0A 2E
>>>
>>
>>
>> As you like it.
> 
> Well done! But that just wins you the Top Eve prize (again). It 
> *doesn't* tell me my algorithm. How did I do the mapping? Not: "Show me 
> the map" which you can obviously do, but "Explain the mapping".
> 

Just what I said: I will try to do this, as you like it. Not there, yet.

[toc] | [prev] | [next] | [standalone]

#50134

On 23.09.21 17:34, Richard Heathfield wrote:




######################################################
#                                                    #
#             POSSIBLE SPOILER AHEAD!                #
#                                                    #
######################################################





> It is not enough to solve this!
> 
> To win, you must be the first to explain the *whole* (very simple) 
> algorithm. The full Monty, please. How, *precisely* have I encrypted 
> this text?
> 
>   74 59 79 39 59 4A 7A 68 09 7B 7A 6D 7A 38 79 30
>   7A 39 09 08 18 51 31 69 09 08 23 2E 1B 54 69 31
>   7A 6D 7A 49 51 31 50 7A 49 79 29 59 7A 39 09 08
>   39 48 51 31 69 09 08 2E 0D 18 7A 50 68 59 31 59
>   7A 49 09 31 50 7A 31 50 30 79 08 19 59 7A 59 10
>   59 08 50 31 0A 2E 6C 59 30 59 1B 31 7A 59 69 19
>   68 50 7A 50 68 79 50 7A 49 51 31 50 7A 50 79 29
>   59 7A 68 79 08 58 31 2E 54 09 7A 28 09 69 08 7A
>   69 08 7A 6C 61 49 59 08 1B 31 7A 38 79 08 58 31
>   4A 2E 6D 18 7A 50 30 51 50 68 7A 68 09 48 58 31
>   7A 50 30 51 59 7A 39 09 08 50 59 08 50 31 0A 2E
>   65 09 51 7A 79 08 58 7A 61 09 51 7A 08 09 7A 39
>   30 09 31 31 7A 31 68 79 48 48 7A 70 79 30 50 23
>   2E 65 09 51 7A 79 08 58 7A 61 09 51 7A 79 30 59
>   7A 68 59 79 30 50 7A 69 08 7A 68 59 79 30 50 23
>   2E 65 09 51 7A 50 09 7A 68 69 31 7A 48 09 10 59
>   7A 49 51 31 50 7A 79 39 39 09 30 58 4A 2E 0D 30
>   7A 68 79 10 59 7A 79 7A 11 09 49 79 08 7A 50 09
>   7A 61 09 51 30 7A 48 09 30 58 23 2E 65 09 51 7A
>   79 08 58 7A 61 09 51 7A 79 30 59 7A 31 51 30 59
>   7A 50 09 19 59 50 68 59 30 4A 2E 7D 31 7A 50 68
>   59 7A 11 69 08 50 59 30 7A 50 09 7A 18 09 51 48
>   7A 11 59 79 50 68 59 30 0A 2E 15 68 69 48 59 31
>   7A 79 7A 11 59 58 48 09 39 29 4B 68 61 49 08 7A
>   11 59 7A 31 69 08 19 4A 2E 1C 59 59 58 7A 61 09
>   51 30 31 59 48 10 59 31 7A 11 69 50 68 7A 71 51
>   59 31 50 69 09 08 69 08 19 4A 2E 54 68 79 50 7A
>   30 59 79 31 09 08 7A 11 09 08 58 59 30 7A 49 79
>   61 7A 58 69 49 69 08 69 31 68 4A 2E 6C 09 11 7A
>   50 68 51 31 7A 11 59 7A 49 59 50 4A 7A 79 08 58
>   7A 50 68 59 31 59 7A 50 68 69 08 19 31 7A 18 69
>   08 69 31 68 0A 2E
> 



So when I xor a plaintext character with its respective ciphertext 
character I get a binary number whose high nibble is a mirror image of 
its low nibble. Plus bit 1 and bit 8 are always zero. Also, this 
difference stays the same for two consecutive characters. Yet, I do not 
see a pattern how to get to the next difference / key pair...

Just saying.

[toc] | [prev] | [next] | [standalone]

#50135

On 25/09/2021 22:03, Max wrote:
> Also, this difference stays the same for two consecutive characters.

I have no idea why that might be. My algorithm did nothing special for 
two consecutive characters. I conclude that you've done your Bright 
Eve[1] thing again and have not discerned my algorithm, although you're 
obviously quite close.

[1] Not *that* bright. :-) This was solvable using standard techniques 
to be found in any cryppie's kitchen drawer, and I have no doubt that's 
how you did it. The one I *was* going to post was more of a bitch but I 
ran out of wossname, motivation to code it up.

-- 
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

[toc] | [prev] | [next] | [standalone]

#50137

On 25.09.21 23:14, Richard Heathfield wrote:
> On 25/09/2021 22:03, Max wrote:





######################################################
#                                                    #
#             POSSIBLE SPOILER AHEAD!                #
#                                                    #
######################################################























######################################################
#                                                    #
#             POSSIBLE SPOILER AHEAD!                #
#                                                    #
######################################################




















>> Also, this difference stays the same for two consecutive characters.
> 
> I have no idea why that might be. My algorithm did nothing special for 
> two consecutive characters. I conclude that you've done your Bright 
> Eve[1] thing again and have not discerned my algorithm, although you're 
> obviously quite close.
> 
> [1] Not *that* bright. :-) This was solvable using standard techniques 
> to be found in any cryppie's kitchen drawer, and I have no doubt that's 
> how you did it. The one I *was* going to post was more of a bitch but I 
> ran out of wossname, motivation to code it up.
> 


Of course. Just by the book (this time the "and"s, not the "the"s). Yet, 
do you really think, it is possible to find the algorithm before finding 
the plaintext? While some person smarter than me might just eyeball the 
CHATX algorithm from the ciphertext, I don't see how this could be done 
here.

The only way I can think of to recover an algorithm is by looking for 
the most simple way to get from the plaintext to the ciphertext, but for 
that I need the plaintext first, don't I?

[toc] | [prev] | [next] | [standalone]

#50139

On 25/09/2021 23:53, Max wrote:
> On 25.09.21 23:14, Richard Heathfield wrote:
>> On 25/09/2021 22:03, Max wrote:
> 
> 
> 
> 
> 
> ######################################################
> #                                                    #
> #             POSSIBLE SPOILER AHEAD!                #
> #                                                    #
> ######################################################
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ######################################################
> #                                                    #
> #             POSSIBLE SPOILER AHEAD!                #
> #                                                    #
> ######################################################
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>>> Also, this difference stays the same for two consecutive characters.
>>
>> I have no idea why that might be. My algorithm did nothing special for 
>> two consecutive characters. I conclude that you've done your Bright 
>> Eve[1] thing again and have not discerned my algorithm, although 
>> you're obviously quite close.
>>
>> [1] Not *that* bright. :-) This was solvable using standard techniques 
>> to be found in any cryppie's kitchen drawer, and I have no doubt 
>> that's how you did it. The one I *was* going to post was more of a 
>> bitch but I ran out of wossname, motivation to code it up.
>>
> 
> 
> Of course. Just by the book (this time the "and"s, not the "the"s). Yet, 
> do you really think, it is possible to find the algorithm before finding 
> the plaintext? While some person smarter than me might just eyeball the 
> CHATX algorithm from the ciphertext, I don't see how this could be done 
> here.

You think I'm being a bit tight? You're probably right. I think on 
reflection(!) I should have given it to you when you talked about 
nybbles being mirror images, even though nybbles had no part of the 
algorithm.

It was pure bit reversal of the middle six bits of each octet:

   while((ch = getchar()) != EOF)
   {
     int i;
     bi = (unsigned char)ch;
     bo = (unsigned char)ch;
     for(i = 1; i < 7; i++)
     {
       int j = 7 - i;
       if(BIT_QRY(p, i))
       {
         BIT_CLR(q, j);
       }
       else
       {
         BIT_SET(q, j);
       }
     }
     putchar(bo);
   }


I left the high bit alone so that ASCII would stay ASCII, and so I left 
the low bit alone for symmetry. I'd have posted the ciphertext as ASCII 
were it not for the fact that I was getting a lot of backspaces in the 
ciphertext, which I thought might confuse the issue.

-- 
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

[toc] | [prev] | [next] | [standalone]

#50145

On 26.09.21 07:59, Richard Heathfield wrote:
> On 25/09/2021 23:53, Max wrote:
>> On 25.09.21 23:14, Richard Heathfield wrote:
>>> On 25/09/2021 22:03, Max wrote:
>>
>>
>>
>>
>>
>> ######################################################
>> #                                                    #
>> #             POSSIBLE SPOILER AHEAD!                #
>> #                                                    #
>> ######################################################
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ######################################################
>> #                                                    #
>> #             POSSIBLE SPOILER AHEAD!                #
>> #                                                    #
>> ######################################################
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>> Also, this difference stays the same for two consecutive characters.
>>>
>>> I have no idea why that might be. My algorithm did nothing special 
>>> for two consecutive characters. I conclude that you've done your 
>>> Bright Eve[1] thing again and have not discerned my algorithm, 
>>> although you're obviously quite close.
>>>
>>> [1] Not *that* bright. :-) This was solvable using standard 
>>> techniques to be found in any cryppie's kitchen drawer, and I have no 
>>> doubt that's how you did it. The one I *was* going to post was more 
>>> of a bitch but I ran out of wossname, motivation to code it up.
>>>
>>
>>
>> Of course. Just by the book (this time the "and"s, not the "the"s). 
>> Yet, do you really think, it is possible to find the algorithm before 
>> finding the plaintext? While some person smarter than me might just 
>> eyeball the CHATX algorithm from the ciphertext, I don't see how this 
>> could be done here.
> 
> You think I'm being a bit tight? You're probably right. I think on 
> reflection(!) I should have given it to you when you talked about 
> nybbles being mirror images, even though nybbles had no part of the 
> algorithm.

No, no, everything is cool. I just thought, it is more fun to not just 
spit out a solution but to discuss the thought process and stuff.
How would you have approached this? Is there a way to go for the 
algorithem/cipher without getting a pair of plaintext/ciphertext first?

> 
> It was pure bit reversal of the middle six bits of each octet:

Ok, so you reversed the order of the bits AND inverted them. I might 
should have seen that, but I didn't. Let's see if others do.

> 
>    while((ch = getchar()) != EOF)
>    {
>      int i;
>      bi = (unsigned char)ch;
>      bo = (unsigned char)ch;
>      for(i = 1; i < 7; i++)
>      {
>        int j = 7 - i;
>        if(BIT_QRY(p, i))
>        {
>          BIT_CLR(q, j);
>        }
>        else
>        {
>          BIT_SET(q, j);
>        }
>      }
>      putchar(bo);
>    }
> 
> 
> I left the high bit alone so that ASCII would stay ASCII, and so I left 
> the low bit alone for symmetry. I'd have posted the ciphertext as ASCII 
> were it not for the fact that I was getting a lot of backspaces in the 
> ciphertext, which I thought might confuse the issue.
> 

Thanks again for another puzzle. It would be interesting to find a 
puzzle that is not a classic hand cipher (substitution, transposition), 
yet breakable, e.g. by differential cryptoanalysis with "small" amounts 
of ciphertext (like 1,000 bytes).

Cheers,

Max

[toc] | [prev] | [next] | [standalone]

#50146

On 26/09/2021 13:40, Max wrote:
> On 26.09.21 07:59, Richard Heathfield wrote:
>> On 25/09/2021 23:53, Max wrote:
>>> On 25.09.21 23:14, Richard Heathfield wrote:
>>>> On 25/09/2021 22:03, Max wrote:
>>>
>>>
>>>
>>>
>>>
>>> ######################################################
>>> #                                                    #
>>> #             POSSIBLE SPOILER AHEAD!                #
>>> #                                                    #
>>> ######################################################
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ######################################################
>>> #                                                    #
>>> #             POSSIBLE SPOILER AHEAD!                #
>>> #                                                    #
>>> ######################################################
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>> Also, this difference stays the same for two consecutive characters.
>>>>
>>>> I have no idea why that might be. My algorithm did nothing special 
>>>> for two consecutive characters. I conclude that you've done your 
>>>> Bright Eve[1] thing again and have not discerned my algorithm, 
>>>> although you're obviously quite close.
>>>>
>>>> [1] Not *that* bright. :-) This was solvable using standard 
>>>> techniques to be found in any cryppie's kitchen drawer, and I have 
>>>> no doubt that's how you did it. The one I *was* going to post was 
>>>> more of a bitch but I ran out of wossname, motivation to code it up.
>>>>
>>>
>>>
>>> Of course. Just by the book (this time the "and"s, not the "the"s). 
>>> Yet, do you really think, it is possible to find the algorithm before 
>>> finding the plaintext? While some person smarter than me might just 
>>> eyeball the CHATX algorithm from the ciphertext, I don't see how this 
>>> could be done here.
>>
>> You think I'm being a bit tight? You're probably right. I think on 
>> reflection(!) I should have given it to you when you talked about 
>> nybbles being mirror images, even though nybbles had no part of the 
>> algorithm.
> 
> No, no, everything is cool. I just thought, it is more fun to not just 
> spit out a solution but to discuss the thought process and stuff.
> How would you have approached this? Is there a way to go for the 
> algorithem/cipher without getting a pair of plaintext/ciphertext first?
> 
>>
>> It was pure bit reversal of the middle six bits of each octet:
> 
> Ok, so you reversed the order of the bits AND inverted them.

Bloody hell! You're right! And that wins you the prize, because 
inverting them was entirely unintentional! I didn't know I'd done it 
until this very moment when you made me look closer, and it wasn't 
revealed in my testing because it is a self-disguising bug that fixes 
itself on decryption!

> Thanks again for another puzzle. It would be interesting to find a 
> puzzle that is not a classic hand cipher (substitution, transposition), 
> yet breakable, e.g. by differential cryptoanalysis with "small" amounts 
> of ciphertext (like 1,000 bytes).

Ah, there you stray out of my ken, my wot, and my dooda. But I agree it 
would be interesting.

(CDX remains uncracked, of course... but it is not a hand cipher.)

-- 
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

[toc] | [prev] | [next] | [standalone]

#50153

On 26.09.21 14:58, Richard Heathfield wrote:
[...]
> 
> (CDX remains uncracked, of course... 

Would you point me to your reference implementation? I'm getting 
confused searching GG for it. Also, what is the current version? CDX3? 
CDX4? fcrypt?

Cheers,

Max

[toc] | [prev] | [next] | [standalone]

#50154

On 26/09/2021 14:54, Max wrote:
> On 26.09.21 14:58, Richard Heathfield wrote:
> [...]
>>
>> (CDX remains uncracked, of course... 
> 
> Would you point me to your reference implementation?

I shall paste it here for you. See below (after sig).

> I'm getting 
> confused searching GG for it.

Uh, yeah, Web site, must do one of those...


> Also, what is the current version? CDX3?
> CDX4? fcrypt?

CDX4

[sig marker removed]
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

To compile:
gcc -o cdx cdx4.c

or:

cl cdx4.c

or:

bcc32 cdx4.c

Or whatever! The code is ISO C90 conforming.

Usage:
./cdx4 inputfile outputfile key_file sbseed [-d]
sbseed seeds the s-boxes.
-d specifies decryption.

Here goes: one file, from here to end of article

/*
  * cdx4.c
  *
  * Cryptographic algorithm by Richard Heathfield
  *
  * First written in 1999.
  * Most recent update: 1 Aug 2017 (code cleanup)
  * Acknowledgements: The 1 Aug 2017 cleanup was a joint
  * exercise by the comp.lang.c newsgroup. Several people
  * chipped in with their observations, but the following
  * should be mentioned in dispatches for particularly
  * relevant contributions:
  *
  * David Brown, Manfred (no surname available), Dan Cross,
  * Ben Bacarisse, Tim Rentsch, Keith Thompson.
  *
  * TODO: rewrite the rotation code to use this technique:
  * (a) reverse all the bits up to n
  * (b) reverse all the bits from n to the end
  * (c) reverse every bit in the buffer
  * Example: ABC|DEFG -> CBA|GFED -> DEFG|ABC
  * (d) express right rotation in terms of left rotation:
  *   bitlen = size * CHAR_BIT;
  *   <<< = >>> (buffer, size, bitlen - n % bitlen, spare)
  *
  * TODO: validate the sbseed to ensure it's < 2^31.
  *
  * What's new in CDX-4
  * 1) sbgen no longer required - sb.c has gone;
  * 2) S-box generation now part of initialisation;
  * 3) to get everything into one C file, CISPRNG
  *    has been incorporated. The CISPRNG code
  *    appears first. You can navigate quickly
  *    to the crypto code by searching for
  *    CRYPTO
  *
  * Basic idea:
  *
  *   Substitution (S-boxes); Rotation (for diffusion); XOR with key.
  *
  *   Conceptually, the algorithm can be considered to
  *   create two circular "rings" of bits, one on top of
  *   the other. The lower ring is free to rotate; it
  *   contains the data to be encrypted. The upper ring
  *   is fixed; it consists of many copies of the key (if it
  *   doesn't fit exactly because L % Keylen is non-zero,
  *   enough bytes of the key are used to fill out the
  *   top ring).
  *
  *   Firstly, the S-boxes are built, using sbseed (command line
  *   argument) as the seed for a PRNG.
  *
  *   Then, in each round:
  *
  *     (1) S-box substitution in the lower ring;
  *     (2) the lower ring is spun a given number of bits;
  *     (3) the upper and lower rings are XORd together,
  *         with the result being stored in the lower ring.
  *
  *   In slightly more detail:
  *
  *     Read whole plaintext into buffer B of length L
  *     One round per key byte (index k)
  *     One round consists of 0 <= i < L:
  *       B[i] = S[Key[k]][B[i]]
  *       B <<<= RotationDistance[Key[k]]
  *       B ^= Key (more precisely, B[i] ^= Key[i % Keylen])
  *
  *     Decryption:
  *       B ^= Key
  *       B >>>= Prime[Key[Keylen - (k + 1)]
  *       B[i] = S'[Key[Keylen - (k + 1)]][B[i]]
  *
  * Usage:
  *   Encryption:
  *   cdx4 plaintextfile ciphertextfile key_file sbseed
  *   Decryption:
  *   cdx4 ciphertextfile plaintextfile key_file sbseed -d
  */

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <limits.h>
#include <assert.h>

/* CISPRNG start */

/* The following #defines: CISPRNG_RAND_MASK, CISPRNG_RAND_MAX
  * must not be changed if you wish to retain interoperability with
  * other users with unmodified sources. For it to *work*,
  * CISPRNG_RAND_MASK /must/ be (2 to the power n) - 1, for
  * some positive integer n. In this application, n must be >= 8
  * because we need numbers in the range 0-255. Frankly, you're
  * better off leaving it well alone!
  */
#define CISPRNG_RAND_MASK (0x7FFFFFFFUL)
#define CISPRNG_RAND_MAX (CISPRNG_RAND_MASK)

static unsigned long CISPRNG_csrandom(unsigned long *pstate)
{
   /* do not change the constants if you wish to retain
    * interoperability with ciphertexts created with
    * unmodified sources.
    *
    * As written, the PRNG has a cipher length of 2^31.
    */
   static const unsigned long multiplier = 0x41C64E6DUL;
   static const unsigned long addend = 0x3039UL;

   assert(pstate != NULL);

   *pstate *= multiplier;
   *pstate += addend;
   *pstate &= CISPRNG_RAND_MASK;
   return *pstate;
}

static unsigned long CISPRNG_csrange(unsigned long *prng_state,
                                      unsigned long low,
                                      unsigned long high)
{
   unsigned long range = 0;
   unsigned long repeats = 0;
   unsigned long ceiling = 0;
   unsigned long r = 0;

   assert(prng_state != NULL);

   low &= CISPRNG_RAND_MASK;
   high &= CISPRNG_RAND_MASK;
   if(low > high)
   {
     unsigned long swap = low;
     low = high;
     high = swap;
   }
   range = 1 + high - low;

   /* Find the highest number we can use
    * that still gives us an even distribution.
    */
   repeats = CISPRNG_RAND_MAX / range;
   ceiling = repeats * range;
   /* Keep rolling until we get a result
    * that comes in under that ceiling.
    */
   do
   {
     r = CISPRNG_csrandom(prng_state);
   } while(r >= ceiling);
   r %= range;
   return r + low;
}

/* CISPRNG end */

/* CRYPTO code starts here */

/* Do not change the number of S-boxes.
  * Do not change the number of characters per S-box.
  * Do not change the number of rotation distances.
  */
#define NUMBOXES 256 /* 256 S-boxes */
#define SBOXSIZE  256 /* 256 characters per S-box */
#define NUMROTDISTS 256 /* 256 possible rotation distances */

/* The following error values must not compare
  * equal to EXIT_SUCCESS or 0, and they must all
  * be different from each other.
  */
#define NO_KEY        1 /* failed to load key file */
#define NO_SPARE_MEM  2 /* failed to alloc reserve buffer */
#define NO_INPUT      3 /* failed to load input file */
#define NO_SBOX_MEM   4 /* failed to alloc memory for S-Boxes */
#define NO_SAVE       5 /* failed to save file */

#define RETAINMASK(n) ((UCHAR_MAX & ~((unsigned char)0)) >> (n))
#define TOPMASK(n) ((unsigned char) (~RETAINMASK((unsigned char)(n))))
#define LOWMASK(n) ((unsigned char) (~((UCHAR_MAX & ~0) << (n))))

/* S-boxes */
struct SBoxGroup_
{
   unsigned char encode[NUMBOXES][SBOXSIZE];
   unsigned char decode[NUMBOXES][SBOXSIZE];
};

typedef struct SBoxGroup_ SBoxGroup;

static void InitialiseSBoxes(SBoxGroup *sbox_group,
                              unsigned long *prng_state)
{
   unsigned int box = 0;

   assert(sbox_group != NULL);
   assert(prng_state != NULL);

   for(box = 0; box < NUMBOXES; box++)
   {
     unsigned int ch = 0;
     unsigned int temp = 0;

     /* initialise box */
     for(ch = 0; ch < SBOXSIZE; ch++)
     {
       sbox_group->encode[box][ch] = ch;
     }
     /* shuffle box */
     ch = SBOXSIZE;
     while(ch > 1)
     {
       unsigned int new = 0;
       --ch;
       new = CISPRNG_csrange(prng_state, 0, ch - 1);
       temp = sbox_group->encode[box][ch];
       sbox_group->encode[box][ch] = sbox_group->encode[box][new];
       sbox_group->encode[box][new] = temp;
     }
     /* calc reverse */
     for(ch = 0; ch < SBOXSIZE; ch++)
     {
       sbox_group->decode[box][sbox_group->encode[box][ch]] = ch;
     }
   }
}
static void InitialiseRotations(unsigned long *rotation_distance,
                                 unsigned long *prng_state)
{
   size_t i = 0;

   assert(rotation_distance != NULL);
   assert(prng_state != NULL);

   while(i < NUMROTDISTS)
   {
     rotation_distance[i++] = CISPRNG_csrandom(prng_state);
   }
}

static unsigned char *LoadFile(const char *filename, size_t *n)
{
   const size_t initial_size = 16384UL;
   size_t current_size = 0;
   unsigned char *tmp = 0;
   unsigned char *buff = NULL;
   size_t count = 0;
   FILE *fp = NULL;

   assert(filename != NULL);
   assert(n != NULL);

   fp = fopen(filename, "rb");
   if(fp != NULL)
   {
     current_size = initial_size;
     buff = malloc(current_size);
     if(buff != NULL)
     {
       int ch = 0;

       while(buff != NULL && (ch = getc(fp)) != EOF)
       {
         if(count >= current_size)
         {
           size_t extra = 1 + current_size / 2;
           size_t new_size = current_size + extra;
           while(extra > 0 && new_size < current_size)
           {
             extra /= 2;
             new_size = current_size + extra;
           }
           if(0 == extra)
           {
             /* can't even /calculate/ a bigger buffer size! */
             tmp = NULL;
           }
           else
           {
             tmp = realloc(buff, new_size);
           }
           if(NULL == tmp)
           {
             free(buff);
             buff = NULL;
           }
           else
           {
             current_size = new_size;
             buff = tmp;
             tmp = NULL;
           }
         }
         if(buff != NULL)
         {
           buff[count++] = ch;
         }
       }
     }
     if(buff != NULL)
     {
       if(0 == count)
       {
         free(buff);
         buff = NULL;
       }
     }

     if(buff != NULL)
     {
       *n = count;

       /* shed any extra memory */
       tmp = realloc(buff, count);
       if(tmp != NULL)
       {
         buff = tmp;
       }
     }
     fclose(fp);
   }
   return buff;
}
static int SaveFile(const char *filename,
                     unsigned char *data,
                     size_t n)
{
   int rc = NO_SAVE; /* failed */
   FILE *fp = NULL;

   /* If we have a 0-length file, something is screwed up.
    * If you remove this function to a library, you might
    * want to consider removing the assertion if you
    * anticipate a need to write 0-length files.
    */
   assert(filename != NULL);
   assert(data != NULL);
   assert(n > 0);

   fp = fopen(filename, "wb");
   if(fp != NULL)
   {
     if(fwrite(data, 1, n, fp) == n)
     {
       rc = EXIT_SUCCESS; /* success */
     }
     fclose(fp);
   }
   return rc;
}

static void XORBuffer(unsigned char *buffer,
                       size_t data_length,
                       unsigned char *key,
                       size_t key_length)
{
    size_t i = 0;

    assert(buffer != NULL);
    assert(key != NULL);

    for(i = 0; i < data_length; i++)
    {
       buffer[i] ^= key[i % key_length];
    }
}

/* accept 'size' bytes and left-rotate them n BITS */
static void RotateBufferLeft(unsigned char *buffer,
                              size_t size,
                              size_t n,
                              unsigned char *spare)
{
    size_t i = 0;
    size_t byte_count = 0;
    unsigned char numbits = 0;
    unsigned char carried_forward = 0;
    unsigned char brought_forward = 0;
    unsigned char topmask = 0;

    assert(buffer != NULL);
    assert(spare != NULL);

    n %= (size * CHAR_BIT);

    byte_count = n / CHAR_BIT;
    memcpy(spare, buffer, byte_count);
    memmove(buffer, buffer + byte_count, size - byte_count);
    memcpy(buffer + size - byte_count, spare, byte_count);
    numbits = n % CHAR_BIT;

    topmask = TOPMASK(numbits);

    carried_forward =
          ((buffer[0] & topmask) >> (CHAR_BIT - numbits));

    for(i = size; i > 0; --i)
    {
      size_t j = i - 1;
      /* 1) Store top numbits bits */
      brought_forward =
          ((buffer[j] & topmask) >> (CHAR_BIT - numbits));

      /* 2) LEFTSHIFT other bits by numbits */
      buffer[j] = buffer[j] << numbits;

      /* 3) BITWISE-AND in the previously shifted numbits
            from byte beforehand */
      buffer[j] |= carried_forward;

      /* 4) carry */
      carried_forward = brought_forward;
    }
}

/* accept 'size' bytes and right-rotate them n BITS */
static void RotateBufferRight(unsigned char *buffer,
                               size_t size,
                               size_t n,
                               unsigned char *spare)
{
    size_t i = 0;
    size_t byte_count = 0;
    unsigned char numbits = 0;
    unsigned char carried_forward = 0;
    unsigned char brought_forward = 0;
    unsigned char lowmask = 0;
    unsigned char left_shift_by = 0;
    unsigned char masked_byte = 0;

    assert(buffer != NULL);
    assert(spare != NULL);

    n %= (size * CHAR_BIT);

    byte_count = n / CHAR_BIT;

    memcpy(spare, buffer + size - byte_count, byte_count);
    memmove(buffer + byte_count, buffer, size - byte_count);
    memcpy(buffer, spare, byte_count);

    numbits = n % CHAR_BIT;
    left_shift_by = CHAR_BIT - numbits;

    lowmask = LOWMASK(numbits);

    masked_byte = buffer[size - 1] & lowmask;
    carried_forward = masked_byte << left_shift_by;

    for(i = 0; i < size; ++i)
    {
      /* 1) Store top numbits bits */
      masked_byte = buffer[i] & lowmask;
      brought_forward =
          (masked_byte << left_shift_by);

      /* 2) Shift other bits by numbits */
      buffer[i] = (buffer[i] >> numbits);

      /* 3) Bitwise-and in the previously shifted
            numbits from byte beforehand */
      buffer[i] |= carried_forward;

      /* 4) carry */
      carried_forward = brought_forward;
    }
}

static void Help(const char *s)
{
   if(!s || *s == '\0')
   {
     s = "./cdx4";
   }
   fprintf(stderr, "Usage:\n");
   fprintf(stderr,
           "%s inputfile outputfile key_file sbseed [-d]\n",
           s);
   fprintf(stderr, "sbseed seeds the s-boxes.\n");
   fprintf(stderr, "-d specifies decryption.\n");
}

static int CheckArgs(int argc,
                      char *argv[],
                      unsigned long *pseed)
{
   int rc = 1;

   assert(argv != NULL);
   assert(pseed != NULL);

   if(argc < 5 ||
     (argc > 5 && strcmp(argv[5], "-d") != 0))
   {
     Help(argv[0]);
     rc = 0;
   }
   else
   {
     char *end_pointer = NULL;

     *pseed = strtoul(argv[4], &end_pointer, 10);

     if(end_pointer == argv[4])
     {
       rc = 0;
     }
   }
   return rc;
}
static void Encrypt(unsigned char *buffer,
                     size_t data_length,
                     unsigned char *key,
                     size_t key_length,
                     unsigned long *rotation_list,
                     unsigned char *spare,
                     SBoxGroup *sbox_group)
{
   size_t key_index = 0;
   size_t data_index = 0;

   assert(buffer != NULL);
   assert(data_length > 0);
   assert(key != NULL);
   assert(key_length > 0);
   assert(rotation_list != NULL);
   assert(spare != NULL);
   assert(sbox_group != NULL);

   for(key_index = 0; key_index < key_length; key_index++)
   {
     putc('.', stderr);

     for(data_index = 0; data_index < data_length; data_index++)
     {
       buffer[data_index] = sbox_group->encode
                     [key[key_index] % NUMBOXES]
                     [buffer[data_index]];
     }
     RotateBufferLeft(buffer,
                      data_length,
                      rotation_list[key[key_index]],
                      spare);
     XORBuffer(buffer, data_length, key, key_length);
   }
}

static void Decrypt(unsigned char *buffer,
                     size_t data_length,
                     unsigned char *key,
                     size_t key_length,
                     unsigned long *rotation_list,
                     unsigned char *spare,
                     SBoxGroup *sbox_group)
{
   size_t key_index = 0;
   size_t data_index = 0;

   assert(buffer != NULL);
   assert(data_length > 0);
   assert(key != NULL);
   assert(key_length > 0);
   assert(rotation_list != NULL);
   assert(spare != NULL);
   assert(sbox_group != NULL);

   for(key_index = 0; key_index < key_length; key_index++)
   {
     putc('.', stderr);
     XORBuffer(buffer, data_length, key, key_length);
     RotateBufferRight(buffer,
                       data_length,
                       rotation_list
                         [key[key_length - (key_index + 1)]],
                       spare);
     for(data_index = 0; data_index < data_length; data_index++)
     {
       buffer[data_index] =
         sbox_group->decode
           [key[key_length - (key_index + 1)] % NUMBOXES]
           [buffer[data_index]];
     }
   }
}
static int CDX4_proc(const char *in_file,
                      const char *out_file,
                      char *key_file,
                      unsigned long *prng_state,
                      int decrypt)
{
   unsigned char *spare = NULL;
   unsigned char *key = NULL;
   size_t key_length = 0;
   size_t data_length = 0;
   unsigned char *buffer = NULL;

   int rc = EXIT_SUCCESS;

   SBoxGroup *sbox_group = malloc(sizeof *sbox_group);

   assert(in_file != NULL);
   assert(key_file != NULL);

   buffer = LoadFile(in_file, &data_length);
   spare = malloc(data_length);
   key = LoadFile(key_file, &key_length);

   if(sbox_group != NULL &&
      buffer     != NULL &&
      spare      != NULL &&
      key        != NULL)
   {
     static unsigned long rotation_distance[NUMROTDISTS] = {0};

     InitialiseSBoxes(sbox_group, prng_state);
     InitialiseRotations(rotation_distance, prng_state);

     if(decrypt)
     {
       Decrypt(buffer, data_length,
               key, key_length,
               rotation_distance,
               spare,
               sbox_group);
     }
     else
     {
       Encrypt(buffer, data_length,
               key, key_length,
               rotation_distance,
               spare,
               sbox_group);
     }
     putc('\n', stderr);

     rc = SaveFile(out_file, buffer, data_length);
   }
   else
   {
     if(NULL == sbox_group)
     {
       rc = NO_SBOX_MEM;
     }
     else if(NULL == buffer)
     {
       rc = NO_INPUT;
     }
     else if(NULL == spare)
     {
       rc = NO_SPARE_MEM;
     }
     else if(NULL == key)
     {
       rc = NO_KEY;
     }
   }

   /* free(NULL) is a well-defined NOP, so we
    * can save all the cleanup for the end.
    */
   free(key);
   free(spare);
   free(buffer);
   free(sbox_group);

   return rc;
}

int main(int argc, char *argv[])
{
   int rc = EXIT_SUCCESS;
   unsigned long sbseed = 0;
   if(!CheckArgs(argc, argv, &sbseed))
   {
     rc = EXIT_FAILURE;
   }
   else
   {
     int decrypt = 0;

     if(argc > 5 && strcmp(argv[5], "-d") == 0)
     {
       decrypt = 1;
     }
     rc = CDX4_proc(argv[1], argv[2], argv[3], &sbseed, decrypt);
     if(rc != EXIT_SUCCESS)
     {
       switch(rc)
       {
         case NO_KEY:
         {
           fprintf(stderr,
                   "Couldn't open load file %s.\n", argv[3]);
           break;
         }
         case NO_SPARE_MEM:
         {
           fprintf(stderr,
                   "Not enough reserve memory.\n");
           break;
         }
         case NO_INPUT:
         {
           fprintf(stderr,
                   "Couldn't load input file %s.\n", argv[1]);
           break;
         }
         case NO_SBOX_MEM:
         {
           fprintf(stderr,
                   "Not enough memory to create"
                   " S-Boxes (64KB reqd).\n");
           break;
         }
         case NO_SAVE:
         {
           fprintf(stderr,
                   "Failed to save file %s.\n", argv[2]);
           break;
         }
         default:
         {
           fprintf(stderr,
                   "Unknown error!\n");
           break;
         }
       }
       rc = EXIT_FAILURE;
     }
   }
   return rc;
}

[toc] | [prev] | [next] | [standalone]

#50157

On 26.09.21 16:06, Richard Heathfield wrote:

[...]

> 
> CDX4
> 

I compiled the source to "cdx4". Then, I made a plaintext-file (128 
"a"s) and a key-file (16 "1"s). Then I run

# cdx4 plaintextfile.txt ciphertext keyfile.txt sbseed

I expected it to create a file "ciphertext" with the generated 
ciphertext. It doesn't. What am I doing wrong?

[...]

[toc] | [prev] | [next] | [standalone]

#50158

On 26/09/2021 16:11, Max wrote:
> On 26.09.21 16:06, Richard Heathfield wrote:
> 
> [...]
> 
>>
>> CDX4
>>
> 
> I compiled the source to "cdx4". Then, I made a plaintext-file (128 
> "a"s) and a key-file (16 "1"s). Then I run
> 
> # cdx4 plaintextfile.txt ciphertext keyfile.txt sbseed

Don't be root. But although that's your problem, it isn't your problem.

> 
> I expected it to create a file "ciphertext" with the generated 
> ciphertext. It doesn't. What am I doing wrong?

sbseed is a numeric seed for the PRNG, used for generating S-boxes. 
Giving it a non-numeric is your problem.

Try, for example:

cdx4 plaintextfile.txt ciphertext keyfile.txt 12345

rjh@here:~/cdx4$ hexhex h < max.in
  61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
  61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
  61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
  61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
  61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
  61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
  61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
  61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
  0A
rjh@here:~/cdx4$ hexhex h < max.key
  31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31
  0A
rjh@here:~/alldata/dev/crypto/cdx/cdx4$ ./cdx4 max.in max.out max.key 12345
.................
rjh@here:~/cdx4$ hexhex h < max.out
  19 AB 60 21 BB 9F 61 CC EA C9 E5 C3 1A 4F BD 56
  8F C9 16 CA 0B F2 31 CF 3D 2B 97 20 E1 CE DB 42
  A6 A0 9B B9 DB 5C 4E AF 62 40 D0 9D F1 C1 13 49
  17 50 78 98 9D 50 3E 99 55 E0 E0 48 59 D3 15 53
  49 12 DF EB 2D 8B 7F 2C 1F 65 82 4E A3 F6 A9 15
  53 49 12 DF EB 2D 8B DE D2 E9 A3 7B D6 35 C6 A9
  15 5E 84 5E 10 1A CF B9 D0 62 E9 A3 78 02 2F AB
  29 A9 67 BA DE 10 1A CC EA C9 E9 73 18 4B E0 BE
  B6


(Note 0A newlines in my plaintext and keyfile)


-- 
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

[toc] | [prev] | [next] | [standalone]

#50159

On 26/09/2021 16:53, Richard Heathfield wrote:
<snip>
> 
> sbseed is a numeric seed for the PRNG, used for generating S-boxes. 
> Giving it a non-numeric is your problem.
> 
> Try, for example:
> 
> cdx4 plaintextfile.txt ciphertext keyfile.txt 12345

By the way, I thought it went without saying, but on reflection perhaps 
it doesn't, that the number you use for sbseed must be the same for 
decryption that you used for encryption.

rjh@here:~/cdx4$ ./cdx4 max.out max.org max.key 12345 -d
.................
rjh@here:~/cdx4$ diff max.in max.org
rjh@here:~/cdx4$

(i.e. decrypt same as orig)

-- 
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

[toc] | [prev] | [next] | [standalone]

#50160

On 26.09.21 17:53, Richard Heathfield wrote:
> On 26/09/2021 16:11, Max wrote:
>> On 26.09.21 16:06, Richard Heathfield wrote:
>>
>> [...]
>>
>>>
>>> CDX4
>>>
>>
>> I compiled the source to "cdx4". Then, I made a plaintext-file (128 
>> "a"s) and a key-file (16 "1"s). Then I run
>>
>> # cdx4 plaintextfile.txt ciphertext keyfile.txt sbseed
> 
> Don't be root. But although that's your problem, it isn't your problem.

I'm not. Thanks for mentioning, I typed the wrong prompt.

> 
>>
>> I expected it to create a file "ciphertext" with the generated 
>> ciphertext. It doesn't. What am I doing wrong?
> 
> sbseed is a numeric seed for the PRNG, used for generating S-boxes. 
> Giving it a non-numeric is your problem.
> 
> Try, for example:
> 
> cdx4 plaintextfile.txt ciphertext keyfile.txt 12345

Cool. Works like a charm now. I thought sbseed was an option/keyword to add.

Is it correct that

plaintext: 
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
(128 x a / 0x61)

key: 1111111111111111
(16 x 1 / 0x31)

seed: 12345

encrypts to:
????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
(128 x ? / 0x3F)

Shouldn't there be a little more diffusion?



> 
> rjh@here:~/cdx4$ hexhex h < max.in
>   61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
>   61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
>   61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
>   61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
>   61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
>   61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
>   61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
>   61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
>   0A
> rjh@here:~/cdx4$ hexhex h < max.key
>   31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31
>   0A
> rjh@here:~/alldata/dev/crypto/cdx/cdx4$ ./cdx4 max.in max.out max.key 12345
> .................
> rjh@here:~/cdx4$ hexhex h < max.out
>   19 AB 60 21 BB 9F 61 CC EA C9 E5 C3 1A 4F BD 56
>   8F C9 16 CA 0B F2 31 CF 3D 2B 97 20 E1 CE DB 42
>   A6 A0 9B B9 DB 5C 4E AF 62 40 D0 9D F1 C1 13 49
>   17 50 78 98 9D 50 3E 99 55 E0 E0 48 59 D3 15 53
>   49 12 DF EB 2D 8B 7F 2C 1F 65 82 4E A3 F6 A9 15
>   53 49 12 DF EB 2D 8B DE D2 E9 A3 7B D6 35 C6 A9
>   15 5E 84 5E 10 1A CF B9 D0 62 E9 A3 78 02 2F AB
>   29 A9 67 BA DE 10 1A CC EA C9 E9 73 18 4B E0 BE
>   B6
> 
> 
> (Note 0A newlines in my plaintext and keyfile)

I purposely omitted the line-break (0x0a) at the end of the plaintext 
and the keyfile. I just wanted the input to be as plain as possible.

> 
> 

[toc] | [prev] | [next] | [standalone]

#50162

On 26/09/2021 17:42, Max wrote:
> On 26.09.21 17:53, Richard Heathfield wrote:
>> On 26/09/2021 16:11, Max wrote:
>>> On 26.09.21 16:06, Richard Heathfield wrote:
>>>
>>> [...]
>>>
>>>>
>>>> CDX4
>>>>
>>>
>>> I compiled the source to "cdx4". Then, I made a plaintext-file (128 
>>> "a"s) and a key-file (16 "1"s). Then I run
>>>
>>> # cdx4 plaintextfile.txt ciphertext keyfile.txt sbseed
>>
>> Don't be root. But although that's your problem, it isn't your problem.
> 
> I'm not. Thanks for mentioning, I typed the wrong prompt.
> 
>>
>>>
>>> I expected it to create a file "ciphertext" with the generated 
>>> ciphertext. It doesn't. What am I doing wrong?
>>
>> sbseed is a numeric seed for the PRNG, used for generating S-boxes. 
>> Giving it a non-numeric is your problem.
>>
>> Try, for example:
>>
>> cdx4 plaintextfile.txt ciphertext keyfile.txt 12345
> 
> Cool. Works like a charm now. I thought sbseed was an option/keyword to 
> add.
> 
> Is it correct that
> 
> plaintext: 
> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 
> 
> (128 x a / 0x61)
> 
> key: 1111111111111111
> (16 x 1 / 0x31)
> 
> seed: 12345
> 
> encrypts to:
> ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 
> 
> (128 x ? / 0x3F)

Yes, that's correct.

> Shouldn't there be a little more diffusion?

Yes. If that helps you crack it, more power to your elbow!

Here's what you get for the same plaintext with a different key

rjh@here:~/cdx4$ ./cdx4 max.in max.out key.32  846786
................................
rjh@here:~/alldata/dev/crypto/cdx/cdx4$ hexhex h < max.out
  2F 6B A7 96 88 9C D6 38 1E 9C 46 A0 3D 01 67 0C
  32 54 E5 F5 B3 F0 88 F8 A4 12 39 1E 20 8A B1 58
  2F 6B A7 96 88 9C D6 38 1E 9C 46 A0 3D 01 67 0C
  32 54 E5 F5 B3 F0 88 F8 A4 12 39 1E 20 8A B1 58
  2F 6B A7 96 88 9C D6 38 1E 9C 46 A0 3D 01 67 0C
  32 54 E5 F5 B3 F0 88 F8 A4 12 39 1E 20 8A B1 58
  2F 6B A7 96 88 9C D6 38 1E 9C 46 A0 3D 01 67 0C
  32 54 E5 F5 B3 F0 88 F8 A4 12 39 1E 20 8A B1 58

Here's the key I used:

  19 55 C8 49 0D 38 B0 1D 03 A4 AA 85 78 BA 7F 9A
  58 7D CA 63 AD 1A C9 A9 31 A5 96 55 5E 88 2C D3

But hey! Maybe you've found a way in?

-- 
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

[toc] | [prev] | [next] | [standalone]

#50164

On 26.09.21 19:27, Richard Heathfield wrote:
<snip>

> 
> But hey! Maybe you've found a way in?
> 

Certainly not. I'm just poking around at this stage. For now I'm 
concerned that long stretches of zeros (other values, too) in the 
plaintext show in the ciphertext, even if the key and the seed are 
non-trivial. This might hold for other repeating patterns, too, but I am 
not there, yet. This results in a repeating pattern in the ciphertext 
that seems to have the length of the key, thus, giving away relevant 
information about the key (its length) and about the plaintext (long 
stretch of repeating data).

One more question: the seed has to be an integer, right? What is the 
valid range for it? At some stage I will take a closer look at the code, 
but for now asking you is the lazy option for me. Hope you don't mind.

Cheers,

Max

[toc] | [prev] | [next] | [standalone]

#50165

Max <maxturv26@gmx.net> writes:

> One more question: the seed has to be an integer, right? What is the
> valid range for it? At some stage I will take a closer look at the
> code, but for now asking you is the lazy option for me. Hope you don't
> mind.

The codes says:

* TODO: validate the sbseed to ensure it's < 2^31.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#50166

On 26.09.21 21:41, Ben Bacarisse wrote:
> Max <maxturv26@gmx.net> writes:
> 
>> One more question: the seed has to be an integer, right? What is the
>> valid range for it? At some stage I will take a closer look at the
>> code, but for now asking you is the lazy option for me. Hope you don't
>> mind.
> 
> The codes says:
> 
> * TODO: validate the sbseed to ensure it's < 2^31.
> 

Thank you, Ben!

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | sci.crypt

csiph-web