Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.crypt > #50203 > unrolled thread
| Started by | Leo <usenet@gkbrk.com> |
|---|---|
| First post | 2021-09-27 21:15 +0000 |
| Last post | 2021-11-01 21:40 +0100 |
| Articles | 20 on this page of 38 — 6 participants |
Back to article view | Back to sci.crypt
Toy cipher I made for a reddit challenge Leo <usenet@gkbrk.com> - 2021-09-27 21:15 +0000
Re: Toy cipher I made for a reddit challenge Richard Heathfield <rjh@cpax.org.uk> - 2021-09-27 23:12 +0100
Re: Toy cipher I made for a reddit challenge Leo <usenet@gkbrk.com> - 2021-09-27 22:32 +0000
Re: Toy cipher I made for a reddit challenge Max <maxturv26@gmx.net> - 2021-09-28 00:51 +0200
Re: Toy cipher I made for a reddit challenge Leo <usenet@gkbrk.com> - 2021-09-28 04:04 -0500
Re: Toy cipher I made for a reddit challenge Richard Heathfield <rjh@cpax.org.uk> - 2021-09-28 11:29 +0100
Re: Toy cipher I made for a reddit challenge wizzofozz <oxxxxxxxxxxxs@gmail.com> - 2021-09-28 21:11 +0200
Re: Toy cipher I made for a reddit challenge Max <maxturv26@gmx.net> - 2021-09-29 00:00 +0200
Re: Toy cipher I made for a reddit challenge wizzofozz <oxxxxxxxxxxxs@gmail.com> - 2021-09-30 23:07 +0200
Re: Toy cipher I made for a reddit challenge wizzofozz <oxxxxxxxxxxxs@gmail.com> - 2021-10-01 22:29 +0200
Re: Toy cipher I made for a reddit challenge Max <maxturv26@gmx.net> - 2021-10-02 04:20 +0200
Re: Toy cipher I made for a reddit challenge Max <maxturv26@gmx.net> - 2021-10-02 12:18 +0200
Re: Toy cipher I made for a reddit challenge wizzofozz <oxxxxxxxxxxxs@gmail.com> - 2021-10-02 13:28 +0200
Re: Toy cipher I made for a reddit challenge Max <maxturv26@gmx.net> - 2021-10-02 16:25 +0200
Re: Toy cipher I made for a reddit challenge wizzofozz <oxxxxxxxxxxxs@gmail.com> - 2021-10-02 17:25 +0200
Re: Toy cipher I made for a reddit challenge wizzofozz <oxxxxxxxxxxxs@gmail.com> - 2021-10-02 12:28 +0200
Re: Toy cipher I made for a reddit challenge Leo <usenet@gkbrk.com> - 2021-10-02 10:42 -0500
Re: Toy cipher I made for a reddit challenge Max <maxturv26@gmx.net> - 2021-10-02 18:13 +0200
Re: Toy cipher I made for a reddit challenge wizzofozz <oxxxxxxxxxxxs@gmail.com> - 2021-10-03 12:27 +0200
Re: Toy cipher I made for a reddit challenge Max <maxturv26@gmx.net> - 2021-10-03 18:02 +0200
Re: Toy cipher I made for a reddit challenge Stefan Claas <spam.trap.usenet@gmail.com> - 2021-10-03 09:23 -0700
Re: Toy cipher I made for a reddit challenge wizzofozz <oxxxxxxxxxxxs@gmail.com> - 2021-10-03 21:32 +0200
Re: Toy cipher I made for a reddit challenge wizzofozz <oxxxxxxxxxxxs@gmail.com> - 2021-10-18 08:52 +0200
Re: Toy cipher I made for a reddit challenge wizzofozz <oxxxxxxxxxxxs@gmail.com> - 2021-10-18 19:24 +0200
Re: Toy cipher I made for a reddit challenge Max <maxturv26@gmx.net> - 2021-10-19 00:47 +0200
Re: Toy cipher I made for a reddit challenge wizzofozz <oxxxxxxxxxxxs@gmail.com> - 2021-10-17 17:17 +0200
Re: Toy cipher I made for a reddit challenge Max <maxturv26@gmx.net> - 2021-10-17 20:05 +0200
Re: Toy cipher I made for a reddit challenge Leo <usenet@gkbrk.com> - 2021-10-25 17:18 -0500
Re: Toy cipher I made for a reddit challenge Max <maxturv26@gmx.net> - 2021-10-26 20:03 +0200
Re: Toy cipher I made for a reddit challenge wizzofozz <oxxxxxxxxxxxs@gmail.com> - 2021-10-27 19:49 +0200
Re: Toy cipher I made for a reddit challenge Leo <usenet@gkbrk.com> - 2021-10-27 17:15 -0500
Re: Toy cipher I made for a reddit challenge Max <maxturv26@gmx.net> - 2021-10-28 12:51 +0200
Re: Toy cipher I made for a reddit challenge wizzofozz <oxxxxxxxxxxxs@gmail.com> - 2021-10-28 13:33 +0200
Re: Toy cipher I made for a reddit challenge wizzofozz <oxxxxxxxxxxxs@gmail.com> - 2021-10-31 22:17 +0100
Re: Toy cipher I made for a reddit challenge Richard Heathfield <rjh@cpax.org.uk> - 2021-10-31 22:38 +0000
Re: Toy cipher I made for a reddit challenge Leo <usenet@gkbrk.com> - 2021-10-31 18:42 -0500
Re: Toy cipher I made for a reddit challenge "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-31 19:30 -0700
Re: Toy cipher I made for a reddit challenge wizzofozz <oxxxxxxxxxxxs@gmail.com> - 2021-11-01 21:40 +0100
Page 1 of 2 [1] 2 Next page →
| From | Leo <usenet@gkbrk.com> |
|---|---|
| Date | 2021-09-27 21:15 +0000 |
| Subject | Toy cipher I made for a reddit challenge |
| Message-ID | <sitca4$518$1@dont-email.me> |
Hi sci.crypt, Around 4 months ago, I posted a small challenge [1] to /r/codes. I removed functionality from the cipher in successive steps in order to make it easier to crack the full thing, but no one there seemed to progress further than the first level. [1]: https://old.reddit.com/r/codes/comments/nk0mcv/ cipher_challenge_with_multiple_levels/ So I figured I'd post some ciphertext here in case anyone finds it a fun challenge. Normally the cipher supports a key and prepends a nonce to messages, but I've left those empty in this post to make this easier to approach. Here is the ciphertext: QVMEJ RZKGX BCQTQ LSJLZ MNBJV IKFER ZERNS OTCCT KSJSX GLEER NUPDB GVTDG PPAQG VLCAE ITZDB IVZUQ MIPYP CNUTC HRDTJ CIAYQ PRDNI BKGVG HNASG YTQIJ VHOGF EHOXA JHDHU HPSNW FCAJU PMHKM WDLHQ YQSFD CMAEB DLDQQ HAMKO KACRD DEVFD HELAC PXBJL JLPIB HPKQE BHFBS JHHPN BXOOY LUYFR RZURG SZZZG XIBYA RCWKD AGUYX VDRNB LBGAJ DPWDE IBPQM HMYTX KZCAY AVWHT TOVNB DKKTG NPIVL XQDXR FZVSH XJUZA NCJKC XDDEH YGXSJ GORGO WNTEA ZHGAO MVXUA YZUTW CKNBF PXCNB UYTUT YBTAG YEQWP HEFSC XCCXQ KSTIY SEJZE PPEFQ HLJKP VUDMP KTYBH BSUTT EPKIO BMGRU CSBFU AAWBM WWSDT IHBSX FYUTL UPMAR LXBSM SGXWS FQNGW XLIHR KZJMI NFFPC YNDWH GNQNE UYQXP JDYUU XNDGY UOELV CJJQG CRJYE VZMQR CECPT RJGRH FSZGH UIFYG CZBDW SJWTX GATCE ITGAL AURHE VOCSE NWVKC UYZYW BWRHV CZHKB CIURC YJTGI YVHVY FNWEV RKHBE SHMXN GDEXV IZJQV QKYNB NPSON SRTXP FWQTP ECAUR BYHAT UYDBS LRQHD DMQEH RTDJA RWFNQ DEEBZ CQJDS FHYMJ RFNLO KDNDJ GNCCB DGATV WIHZL DLMWX SGEGF FWEZL WQSJO PKYIL JVGGQ BBSCS QSMFS IDYTM QEHYY ULUSM JWNKP KGSPN HUFIR OZMDB AVMEH UXQCN CYHQL ZOJET LAGFL HXDFD JPSSY ZECAS QAYEM SNZGE RNIBD WQWHY VNXNN BIZIX UANLB SWEIT PEGCR IGQCK WMMDQ SQZPD AZFDS ELPCD XYWXZ LH And the plaintext for it: > Quentin Coldwater is a high school student from Brooklyn who along > with best friends James and Julia attends an advanced school He > loves a series of books called Fillory and Further which involve the > children of the Chatwin family discovering a Narniaesque magical > land called Fillory On the day of his Princeton interview Quentin is > instead transported to Brakebills College for Magical Pedagogy the > only school for magic in North America He passes the tests and > interviews is accepted as one of twenty new students After beginning > his studies at Brakebills it becomes apparent that magic is > difficult and tedious to learn The curriculum involves learning many > old and lost languages and innumerable hand positions Despite this > Quentin and his classmates Penny and Alice are allowed to move up a > year by compressing their first year of studies Penny fails the > special exam and stays behind then later fistfights Quentin out of > jealousy One day during class a bored Quentin tampers with a spell > An otherworldly horror referred to as the Beast enters Brakebills > eating a student before the faculty are able to drive it away As for the challenge, try decoding the following ciphertext, encrypted in exactly the same way. IDPIP INPZN EGLQZ JSQLX MVLFE RSBJV ZIOJJ MDPCD JQQRF VYZYV UAIAU XDHFT WXDWJ HYFOD OIVZZ VMORF SOXPA GOPUW MURKC EMKYR YPPCE IIIGL KUODI HZJCV DPRWU LMJDS NNPOR IRKKU AMWPR HQJNB WPWSE UEWAR LEDHD XOGOV RSOLE XQNSF BKUHI AKVAR JLLVX RKQOS EPSPR RVEZK KJHOM ATCDH GDGNA MCSRW IOAQO LCMOZ XWEOG EHVCQ QVOZC SELQD LXMXK UFNOT RGOOE QQWIF USQFN CCYNY QULVA VNUFR YQKOD DLCVH LWYB -- Leo
[toc] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2021-09-27 23:12 +0100 |
| Message-ID | <sitfla$nn9$1@dont-email.me> |
| In reply to | #50203 |
On 27/09/2021 22:15, Leo wrote: > Hi sci.crypt, > > Around 4 months ago, I posted a small challenge [1] to /r/codes. I Observations: ciphertext 1143 octets, 28 unique symbols. plaintext 1123 octets, 40 unique symbols. The sizes are a close match, the symbol counts not so much. ciphertext is the wrong shape for a mono: Code 32 ( ) 187 ( 16.36%) Code 68 ( D) 47 ( 4.11%) Code 72 ( H) 46 ( 4.02%) Code 69 ( E) 45 ( 3.94%) Code 67 ( C) 44 ( 3.85%) Code 83 ( S) 44 ( 3.85%) Code 71 ( G) 43 ( 3.76%) Code 89 ( Y) 42 ( 3.67%) Code 66 ( B) 41 ( 3.59%) Code 78 ( N) 40 ( 3.50%) Code 81 ( Q) 40 ( 3.50%) Code 65 ( A) 36 ( 3.15%) Code 80 ( P) 36 ( 3.15%) Code 84 ( T) 36 ( 3.15%) Code 74 ( J) 35 ( 3.06%) Code 82 ( R) 34 ( 2.97%) plaintext for comparison: Code 32 ( ) 169 ( 15.05%) Code 101 ( e) 107 ( 9.53%) Code 97 ( a) 82 ( 7.30%) Code 116 ( t) 74 ( 6.59%) Code 105 ( i) 72 ( 6.41%) Code 110 ( n) 72 ( 6.41%) Code 115 ( s) 69 ( 6.14%) Code 111 ( o) 57 ( 5.08%) Code 108 ( l) 55 ( 4.90%) Code 114 ( r) 53 ( 4.72%) Code 100 ( d) 41 ( 3.65%) Code 104 ( h) 35 ( 3.12%) Code 99 ( c) 27 ( 2.40%) Code 117 ( u) 25 ( 2.23%) Code 102 ( f) 21 ( 1.87%) Code 121 ( y) 20 ( 1.78%) <snip> -- 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]
| From | Leo <usenet@gkbrk.com> |
|---|---|
| Date | 2021-09-27 22:32 +0000 |
| Message-ID | <sitgp5$518$2@dont-email.me> |
| In reply to | #50204 |
On Mon, 27 Sep 2021 23:12:58 +0100, Richard Heathfield wrote: > On 27/09/2021 22:15, Leo wrote: >> Hi sci.crypt, >> >> Around 4 months ago, I posted a small challenge [1] to /r/codes. I > > Observations: > > ciphertext 1143 octets, 28 unique symbols. > > plaintext 1123 octets, 40 unique symbols. > > The sizes are a close match, the symbol counts not so much. > > ciphertext is the wrong shape for a mono: > > Code 32 ( ) 187 ( 16.36%) > plaintext for comparison: > Code 32 ( ) 169 ( 15.05%) I should have mentioned that whitespace is ignored and not turned into any characters. Only letters are kept, and no uppercase/lowercase distinction either. There should be a one-to-one mapping between ciphertext and plaintext. It is just formatted into groups of five because of convention :P -- Leo
[toc] | [prev] | [next] | [standalone]
| From | Max <maxturv26@gmx.net> |
|---|---|
| Date | 2021-09-28 00:51 +0200 |
| Message-ID | <sithua$1ehq$1@gioia.aioe.org> |
| In reply to | #50204 |
On 28.09.21 00:12, Richard Heathfield wrote: > On 27/09/2021 22:15, Leo wrote: >> Hi sci.crypt, >> >> Around 4 months ago, I posted a small challenge [1] to /r/codes. I > > Observations: > > ciphertext 1143 octets, 28 unique symbols. > > plaintext 1123 octets, 40 unique symbols. > > The sizes are a close match, the symbol counts not so much. > > ciphertext is the wrong shape for a mono: > [...] Bigrams (max: 8) and trigrams (max: 3) are very evenly distributed, as well.
[toc] | [prev] | [next] | [standalone]
| From | Leo <usenet@gkbrk.com> |
|---|---|
| Date | 2021-09-28 04:04 -0500 |
| Message-ID | <BoednbEc4OYqR8_8nZ2dnUU7-d-dnZ2d@giganews.com> |
| In reply to | #50206 |
On Tue, 28 Sep 2021 00:51:54 +0200, Max wrote: > On 28.09.21 00:12, Richard Heathfield wrote: >> On 27/09/2021 22:15, Leo wrote: >>> Hi sci.crypt, >>> >>> Around 4 months ago, I posted a small challenge [1] to /r/codes. I >> >> Observations: >> >> ciphertext 1143 octets, 28 unique symbols. >> >> plaintext 1123 octets, 40 unique symbols. >> >> The sizes are a close match, the symbol counts not so much. >> >> ciphertext is the wrong shape for a mono: >> > [...] > > Bigrams (max: 8) and trigrams (max: 3) are very evenly distributed, as > well. It looks like either everyone is busy with other things, or the cipher is not complete crap. One flaw that should be visible from the examples so far is that without a key or nonce, the first character of the ciphertext is the first character of the plaintext. IUESU QEDLL EVVTQ ZGKQG YVROR MGXKS LAOKN XBKRA XMQTZ RBWSV WOUQK APTED VPYPG JECAR WVMN becomes ITLOO KSLIK EEITH EREVE RYONE ISBUS YWITH OTHER THING SORTH ECIPH ERISN OTCOM PLETE CRAP -- Leo
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2021-09-28 11:29 +0100 |
| Message-ID | <siuqq9$pfh$1@dont-email.me> |
| In reply to | #50211 |
On 28/09/2021 10:04, Leo wrote: > On Tue, 28 Sep 2021 00:51:54 +0200, Max wrote: > >> On 28.09.21 00:12, Richard Heathfield wrote: >>> On 27/09/2021 22:15, Leo wrote: >>>> Hi sci.crypt, >>>> >>>> Around 4 months ago, I posted a small challenge [1] to /r/codes. I >>> >>> Observations: >>> >>> ciphertext 1143 octets, 28 unique symbols. >>> >>> plaintext 1123 octets, 40 unique symbols. >>> >>> The sizes are a close match, the symbol counts not so much. >>> >>> ciphertext is the wrong shape for a mono: >>> >> [...] >> >> Bigrams (max: 8) and trigrams (max: 3) are very evenly distributed, as >> well. > > It looks like either everyone is busy with other things, or the cipher > is not complete crap. I suspect there's simply a limit on how long people are prepared to spend on guessing games. In my two recent challenges I provided very large hooks - a ciphertext that rewarded staring at, and a ciphertext that had "mono" written all over it. You have provided no hooks, so there's nothing to tempt the solver further. -- 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]
| From | wizzofozz <oxxxxxxxxxxxs@gmail.com> |
|---|---|
| Date | 2021-09-28 21:11 +0200 |
| Message-ID | <sivpc9$av7$1@dont-email.me> |
| In reply to | #50211 |
Op 28-9-2021 om 11:04 schreef Leo: > On Tue, 28 Sep 2021 00:51:54 +0200, Max wrote: > >> On 28.09.21 00:12, Richard Heathfield wrote: >>> On 27/09/2021 22:15, Leo wrote: >>>> Hi sci.crypt, >>>> >>>> Around 4 months ago, I posted a small challenge [1] to /r/codes. I >>> >>> Observations: >>> >>> ciphertext 1143 octets, 28 unique symbols. >>> >>> plaintext 1123 octets, 40 unique symbols. >>> >>> The sizes are a close match, the symbol counts not so much. >>> >>> ciphertext is the wrong shape for a mono: >>> >> [...] >> >> Bigrams (max: 8) and trigrams (max: 3) are very evenly distributed, as >> well. > > It looks like either everyone is busy with other things, or the cipher > is not complete crap. It could also be both. Anyway, I'll have a look it at, but I only can spend an hour or so per night during the week. Ozz
[toc] | [prev] | [next] | [standalone]
| From | Max <maxturv26@gmx.net> |
|---|---|
| Date | 2021-09-29 00:00 +0200 |
| Message-ID | <sj03aq$puk$1@dont-email.me> |
| In reply to | #50214 |
On 28.09.21 21:11, wizzofozz wrote:
> Op 28-9-2021 om 11:04 schreef Leo:
>> On Tue, 28 Sep 2021 00:51:54 +0200, Max wrote:
>>
>>> On 28.09.21 00:12, Richard Heathfield wrote:
>>>> On 27/09/2021 22:15, Leo wrote:
>>>>> Hi sci.crypt,
>>>>>
>>>>> Around 4 months ago, I posted a small challenge [1] to /r/codes. I
>>>>
>>>> Observations:
>>>>
>>>> ciphertext 1143 octets, 28 unique symbols.
>>>>
>>>> plaintext 1123 octets, 40 unique symbols.
>>>>
>>>> The sizes are a close match, the symbol counts not so much.
>>>>
>>>> ciphertext is the wrong shape for a mono:
>>>>
>>> [...]
>>>
>>> Bigrams (max: 8) and trigrams (max: 3) are very evenly distributed, as
>>> well.
>>
>> It looks like either everyone is busy with other things, or the cipher
>> is not complete crap.
>
> It could also be both. Anyway, I'll have a look it at, but I only can
> spend an hour or so per night during the week.
>
> Ozz
>
It's worth taking a look at the reddit post Leo linked in the OP. There
are many plaintext/ciphertext pairs. There are obviously different
levels of the cipher with different avalanche effects
(none/forward/whole message).
The first challenge ("babbylevel") is just a simple monoalphabetic
substitution with this mapping:
abcdefghijklmnopqrstuvwxyz
WVUPMOABCDEFGXY??LKQRST?I?
Yet, how the key "babbylevelsoeasy" generates this mapping idk. I guess
it is a good idea to find out how the mapping works first to see how
Aleoce ticks.
*Quote*
Babby level
The key is babbylevelsoeasy.
Good morning everyone my name is michael ->
AYYPG YLXCX AMSML IYXMG IXWGM CKGCU BWMF
Why is reddit so slow these days ->
TBICK LMPPC QKYKF YTQBM KMPWI K
What is the decryption of CVMQM SMLIY XMUWX OCARL MQBCK YXMYR Q?
*/Quote*
[toc] | [prev] | [next] | [standalone]
| From | wizzofozz <oxxxxxxxxxxxs@gmail.com> |
|---|---|
| Date | 2021-09-30 23:07 +0200 |
| Message-ID | <sj58uc$nlj$1@dont-email.me> |
| In reply to | #50218 |
Op 29-9-2021 om 00:00 schreef Max:
> On 28.09.21 21:11, wizzofozz wrote:
>> Op 28-9-2021 om 11:04 schreef Leo:
>>> On Tue, 28 Sep 2021 00:51:54 +0200, Max wrote:
>>>
>>>> On 28.09.21 00:12, Richard Heathfield wrote:
>>>>> On 27/09/2021 22:15, Leo wrote:
>>>>>> Hi sci.crypt,
>>>>>>
>>>>>> Around 4 months ago, I posted a small challenge [1] to /r/codes. I
>>>>>
>>>>> Observations:
>>>>>
>>>>> ciphertext 1143 octets, 28 unique symbols.
>>>>>
>>>>> plaintext 1123 octets, 40 unique symbols.
>>>>>
>>>>> The sizes are a close match, the symbol counts not so much.
>>>>>
>>>>> ciphertext is the wrong shape for a mono:
>>>>>
>>>> [...]
>>>>
>>>> Bigrams (max: 8) and trigrams (max: 3) are very evenly distributed, as
>>>> well.
>>>
>>> It looks like either everyone is busy with other things, or the cipher
>>> is not complete crap.
>>
>> It could also be both. Anyway, I'll have a look it at, but I only can
>> spend an hour or so per night during the week.
>>
>> Ozz
>>
>
> It's worth taking a look at the reddit post Leo linked in the OP. There
> are many plaintext/ciphertext pairs. There are obviously different
> levels of the cipher with different avalanche effects
> (none/forward/whole message).
>
good tip.
> The first challenge ("babbylevel") is just a simple monoalphabetic
> substitution with this mapping:
>
> abcdefghijklmnopqrstuvwxyz
> WVUPMOABCDEFGXY??LKQRST?I?
>
> Yet, how the key "babbylevelsoeasy" generates this mapping idk. I guess
> it is a good idea to find out how the mapping works first to see how
> Aleoce ticks.
I don't have it yet, but I was thinking along the lines of swapping
parts of the alphabet in as many rounds as there are characters in the key.
Also, "WUV" is reverse, but "ABCDEFG" is not, so not every half is
swapped the same number of times.
Here's my code for inspiration (if you care) which generates these kind
of permutations (not the exact permutation but that's WIP).
genmap:
import sys
alf='ABCDEFGHIJKLMNOPQRSTUVWXYZ'
k=sys.argv[1]
def revs(alf,c):
a='abcdefghijklmnopqrstuvwxyz'
x=a.find(c)
print x
a1=[k for k in alf[x:]]
a2=[k for k in alf[:x]]
a1.reverse()
# a2.reverse()
return "".join(a2)+"".join(a1)
for c in k:
print alf,c
alf=revs(alf,c)
print alf
python genmap babbylevelsoeasy
ABCDEFGHIJKLMNOPQRSTUVWXYZ b
1
AZYXWVUTSRQPONMLKJIHGFEDCB a
0
BCDEFGHIJKLMNOPQRSTUVWXYZA b
1
BAZYXWVUTSRQPONMLKJIHGFEDC b
1
BCDEFGHIJKLMNOPQRSTUVWXYZA y
24
BCDEFGHIJKLMNOPQRSTUVWXYAZ l
11
BCDEFGHIJKLZAYXWVUTSRQPONM e
4
BCDEMNOPQRSTUVWXYAZLKJIHGF v
21
BCDEMNOPQRSTUVWXYAZLKFGHIJ e
4
BCDEJIHGFKLZAYXWVUTSRQPONM l
11
BCDEJIHGFKLMNOPQRSTUVWXYAZ s
18
BCDEJIHGFKLMNOPQRSZAYXWVUT o
14
BCDEJIHGFKLMNOTUVWXYAZSRQP e
4
BCDEPQRSZAYXWVUTONMLKFGHIJ a
0
JIHGFKLMNOTUVWXYAZSRQPEDCB s
18
JIHGFKLMNOTUVWXYAZBCDEPQRS y
24
JIHGFKLMNOTUVWXYAZBCDEPQSR
[toc] | [prev] | [next] | [standalone]
| From | wizzofozz <oxxxxxxxxxxxs@gmail.com> |
|---|---|
| Date | 2021-10-01 22:29 +0200 |
| Message-ID | <sj7r3v$avt$1@dont-email.me> |
| In reply to | #50257 |
Op 30-9-2021 om 23:07 schreef wizzofozz:
> Op 29-9-2021 om 00:00 schreef Max:
>
>> The first challenge ("babbylevel") is just a simple monoalphabetic
>> substitution with this mapping:
>>
>> abcdefghijklmnopqrstuvwxyz
>> WVUPMOABCDEFGXY??LKQRST?I?
>>
For now I assume the full mapping is:
WVUPMOABCDEFGXYZNLKQRSTHIJ
Perhaps Aleoce could post another plain-ciphertext pair (containing the
missing characters) so that we know for sure.
> I don't have it yet, but I was thinking along the lines of swapping
> parts of the alphabet in as many rounds as there are characters in the key.
> Also, "WVU" is reverse, but "ABCDEFG" is not, so not every half is
> swapped the same number of times.
I'm still thinking along these lines. My current 'swap' algorithm
generates stuff like WVUTSRQPONMYXZABCDEFGLKJIH, which is pretty close
(not really, but ok):
WVU and ABCDEFG are in the correct order.
ABCDEFG is concatenated to XYZ (only on the wrong side, and XYZ is
shuffled).
JIH is on correct position only reversed (but we don't know the mapping
for sure, it could be correct).
LK is correct but wrong position.
The big problem now is that this string is generated after processing of
the partial key "babbyleve".
This is my current program (I have 4 variations of it, but this one
seems to be most "accurate"):
import sys
alf='ABCDEFGHIJKLMNOPQRSTUVWXYZ'
k=sys.argv[1]
def revs(alf,c,i):
x=ord(c)-ord('a')
a1=[k for k in alf[x:]]
a2=[k for k in alf[:x]]
if i % 2:
a1.reverse()
else:
a2.reverse()
return "".join(a2)+"".join(a1)
i=0
for c in k:
print alf,c
alf=revs(alf,c,i)
i += 1
print alf
I have 4 versions because of the "if i % 2:" (init i to 1 instead of 0)
combined with how a2 and a1 are returned (swap them).
I hope the babbylevelsoeasy is not much harder than this :-)
Ozz
[toc] | [prev] | [next] | [standalone]
| From | Max <maxturv26@gmx.net> |
|---|---|
| Date | 2021-10-02 04:20 +0200 |
| Message-ID | <sj8fl6$b86$1@gioia.aioe.org> |
| In reply to | #50278 |
On 01.10.21 22:29, wizzofozz wrote:
> Op 30-9-2021 om 23:07 schreef wizzofozz:
>> Op 29-9-2021 om 00:00 schreef Max:
>>
>>> The first challenge ("babbylevel") is just a simple monoalphabetic
>>> substitution with this mapping:
>>>
>>> abcdefghijklmnopqrstuvwxyz
>>> WVUPMOABCDEFGXY??LKQRST?I?
>>>
>
> For now I assume the full mapping is:
>
> WVUPMOABCDEFGXYZNLKQRSTHIJ
Makes sense. I'll work with this for now.
So, the key has 16 letters. The alphabet has 26. There is a stretch of 7
"unchanged" letters, at the beginning of the alphabet "ABCDEFG" and 3
"unchanged" letters as the end of the alphabet "XYZ".
What if this algorithm works "inside out", taking single letters from
the middle of the alphabet and deciding to put it at the beginning oŕ at
the end? That would also explain, that the backwards-stretch "WVU" is at
the beginning, not at the end of the key.
Let's see:
ABCDEFGHIJKLMNOPQRSTUVWXYZ
b ABCDEFGHIJKLM*OPQRSTUVWXYZN
a OABCDEFGHIJKLM-*PQRSTUVWXYZN
b MOABCDEFGHIJKL*--PQRSTUVWXYZN
b MOABCDEFGHIJK*---PQRSTUVWXYZNL
y MOABCDEFGHIJ*----PQRSTUVWXYZNLK
l PMOABCDEFGHIJ-----*QRSTUVWXYZNLK
e PMOABCDEFGHIJ------*RSTUVWXYZNLKQ
v PMOABCDEFGHIJ-------*STUVWXYZNLKQR
e PMOABCDEFGHIJ--------*TUVWXYZNLKQRS
l PMOABCDEFGHIJ---------*UVWXYZNLKQRST
s UPMOABCDEFGHIJ----------*VWXYZNLKQRST
o VUPMOABCDEFGHIJ-----------*WXYZNLKQRST
e WVUPMOABCDEFGHIJ------------*XYZNLKQRST
a WVUPMOABCDEFGHI*-------------XYZNLKQRSTJ
s WVUPMOABCDEFGH*--------------XYZNLKQRSTJI
y WVUPMOABCDEFG*---------------XYZNLKQRSTJIH
This looks promising.
That would also mean that the full mapping is
WVUPMOABCDEFGXYZNLKQRSTJIH
which is also consistent with the letters we know.
So, the question remains: When will I take a letter from the right vs.
the left side and when do I put it to the right or to the left?
key: babbylevelsoeasy
I start in the middle, between M and N.
"b" means: take the right of the two "inner letters" and put it to the
right end, this means:
b : right => right
a : right => left
b : left => left
b : left => right
y : left => right
l : right => left
e : right => right
v : right => right
e : right => right
l : right => right
s : right => left
o : right => left
e : right => left
a : left => right
s : left => right
y : left => right
I don't see an easy mapping here and it's too late for a tricky one.
Maybe tomorrow. Maybe you see something in this that I don't see.
> I'm still thinking along these lines. My current 'swap' algorithm
> generates stuff like WVUTSRQPONMYXZABCDEFGLKJIH, which is pretty close
[...]
Not bad. The code is simple enough and the result is indeed pretty
close. Yet, for now, I tend towards my approach.
>
> I hope the babbylevelsoeasy is not much harder than this :-)
:-)
>
> Ozz
Cheers,
Max
[toc] | [prev] | [next] | [standalone]
| From | Max <maxturv26@gmx.net> |
|---|---|
| Date | 2021-10-02 12:18 +0200 |
| Message-ID | <sj9bli$1ui7$1@gioia.aioe.org> |
| In reply to | #50288 |
On 02.10.21 04:20, Max wrote:
> On 01.10.21 22:29, wizzofozz wrote:
>> Op 30-9-2021 om 23:07 schreef wizzofozz:
>>> Op 29-9-2021 om 00:00 schreef Max:
>>>
>>>> The first challenge ("babbylevel") is just a simple monoalphabetic
>>>> substitution with this mapping:
>>>>
>>>> abcdefghijklmnopqrstuvwxyz
>>>> WVUPMOABCDEFGXY??LKQRST?I?
>>>>
>>
>> For now I assume the full mapping is:
>>
>> WVUPMOABCDEFGXYZNLKQRSTHIJ
>
> Makes sense. I'll work with this for now.
> So, the key has 16 letters. The alphabet has 26. There is a stretch of 7
> "unchanged" letters, at the beginning of the alphabet "ABCDEFG" and 3
> "unchanged" letters as the end of the alphabet "XYZ".
>
> What if this algorithm works "inside out", taking single letters from
> the middle of the alphabet and deciding to put it at the beginning oŕ at
> the end? That would also explain, that the backwards-stretch "WVU" is at
> the beginning, not at the end of the key.
>
> Let's see:
>
> ABCDEFGHIJKLMNOPQRSTUVWXYZ
> b ABCDEFGHIJKLM*OPQRSTUVWXYZN
> a OABCDEFGHIJKLM-*PQRSTUVWXYZN
> b MOABCDEFGHIJKL*--PQRSTUVWXYZN
> b MOABCDEFGHIJK*---PQRSTUVWXYZNL
> y MOABCDEFGHIJ*----PQRSTUVWXYZNLK
> l PMOABCDEFGHIJ-----*QRSTUVWXYZNLK
> e PMOABCDEFGHIJ------*RSTUVWXYZNLKQ
> v PMOABCDEFGHIJ-------*STUVWXYZNLKQR
> e PMOABCDEFGHIJ--------*TUVWXYZNLKQRS
> l PMOABCDEFGHIJ---------*UVWXYZNLKQRST
> s UPMOABCDEFGHIJ----------*VWXYZNLKQRST
> o VUPMOABCDEFGHIJ-----------*WXYZNLKQRST
> e WVUPMOABCDEFGHIJ------------*XYZNLKQRST
> a WVUPMOABCDEFGHI*-------------XYZNLKQRSTJ
> s WVUPMOABCDEFGH*--------------XYZNLKQRSTJI
> y WVUPMOABCDEFG*---------------XYZNLKQRSTJIH
Ok. This isn't the only possible order in which to sort the letters.
Some steps are forced, but not all. E.g., for the 3rd b one could either
move the L to the right or the P to the left. This creates a tree. Have
to dig into this later.
>
> This looks promising.
>
> That would also mean that the full mapping is
>
> WVUPMOABCDEFGXYZNLKQRSTJIH
>
> which is also consistent with the letters we know.
>
> So, the question remains: When will I take a letter from the right vs.
> the left side and when do I put it to the right or to the left?
>
> key: babbylevelsoeasy
>
> I start in the middle, between M and N.
>
> "b" means: take the right of the two "inner letters" and put it to the
> right end, this means:
>
> b : right => right
> a : right => left
> b : left => left
> b : left => right
> y : left => right
> l : right => left
> e : right => right
> v : right => right
> e : right => right
> l : right => right
> s : right => left
> o : right => left
> e : right => left
> a : left => right
> s : left => right
> y : left => right >
> I don't see an easy mapping here and it's too late for a tricky one.
> Maybe tomorrow. Maybe you see something in this that I don't see.
>
> > I'm still thinking along these lines. My current 'swap' algorithm
> > generates stuff like WVUTSRQPONMYXZABCDEFGLKJIH, which is pretty close
>
> [...]
>
> Not bad. The code is simple enough and the result is indeed pretty
> close. Yet, for now, I tend towards my approach.
>
>>
>> I hope the babbylevelsoeasy is not much harder than this :-)
>
> :-)
>
>>
>> Ozz
>
> Cheers,
>
> Max
>
[toc] | [prev] | [next] | [standalone]
| From | wizzofozz <oxxxxxxxxxxxs@gmail.com> |
|---|---|
| Date | 2021-10-02 13:28 +0200 |
| Message-ID | <sj9fo1$9dd$1@dont-email.me> |
| In reply to | #50291 |
Op 2-10-2021 om 12:18 schreef Max:
>
> Ok. This isn't the only possible order in which to sort the letters.
> Some steps are forced, but not all. E.g., for the 3rd b one could either
> move the L to the right or the P to the left. This creates a tree. Have
> to dig into this later.
>
I just tested with an implementation which uses a "left list" and "right
list". I think this slightly different from :
> "b" means: take the right of the two "inner letters" and put it to
the > right end, this means:
You can also think:
"b" means: take the first (/last) letter of the right (/left) list and
put it to the end (/beginning) of the right (/left) list.
This way, the lists are growing and shrinking and I get slightly
different results (in my editor the below text hurts your eyes, but if
aligned you may see what I mean):
python brute.py babbylevelsoeasy 1 1
['A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M']
['N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z']
b ['A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L'] ['N',
'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', 'M']
a ['N', 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L']
['O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', 'M']
b ['N', 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K'] ['O',
'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', 'M', 'L']
b ['N', 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J'] ['O', 'P',
'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', 'M', 'L', 'K']
y ['O', 'N', 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J'] ['P',
'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', 'M', 'L', 'K']
l ['O', 'N', 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I'] ['P', 'Q',
'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', 'M', 'L', 'K', 'J']
e ['P', 'O', 'N', 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I'] ['Q',
'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', 'M', 'L', 'K', 'J']
v ['P', 'O', 'N', 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H'] ['Q', 'R',
'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', 'M', 'L', 'K', 'J', 'I']
e ['Q', 'P', 'O', 'N', 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H'] ['R',
'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', 'M', 'L', 'K', 'J', 'I']
l ['Q', 'P', 'O', 'N', 'A', 'B', 'C', 'D', 'E', 'F', 'G'] ['R', 'S',
'T', 'U', 'V', 'W', 'X', 'Y', 'Z', 'M', 'L', 'K', 'J', 'I', 'H']
s ['R', 'Q', 'P', 'O', 'N', 'A', 'B', 'C', 'D', 'E', 'F', 'G'] ['S',
'T', 'U', 'V', 'W', 'X', 'Y', 'Z', 'M', 'L', 'K', 'J', 'I', 'H']
o ['S', 'R', 'Q', 'P', 'O', 'N', 'A', 'B', 'C', 'D', 'E', 'F', 'G']
['T', 'U', 'V', 'W', 'X', 'Y', 'Z', 'M', 'L', 'K', 'J', 'I', 'H']
e ['T', 'S', 'R', 'Q', 'P', 'O', 'N', 'A', 'B', 'C', 'D', 'E', 'F', 'G']
['U', 'V', 'W', 'X', 'Y', 'Z', 'M', 'L', 'K', 'J', 'I', 'H']
a ['U', 'T', 'S', 'R', 'Q', 'P', 'O', 'N', 'A', 'B', 'C', 'D', 'E', 'F',
'G'] ['V', 'W', 'X', 'Y', 'Z', 'M', 'L', 'K', 'J', 'I', 'H']
s ['V', 'U', 'T', 'S', 'R', 'Q', 'P', 'O', 'N', 'A', 'B', 'C', 'D', 'E',
'F', 'G'] ['W', 'X', 'Y', 'Z', 'M', 'L', 'K', 'J', 'I', 'H']
y ['W', 'V', 'U', 'T', 'S', 'R', 'Q', 'P', 'O', 'N', 'A', 'B', 'C', 'D',
'E', 'F', 'G'] ['X', 'Y', 'Z', 'M', 'L', 'K', 'J', 'I', 'H']
Some code:
#!/usr/bin/python
import sys
k=sys.argv[1]
i=int(sys.argv[2]) # set to 0 or 1 to toggle the ifs
j=int(sys.argv[3]) # dito
al=[c for c in "ABCDEFGHIJKLM"]
ar=[c for c in "NOPQRSTUVWXYZ"]
def round(c,al,ar):
n=ord(c)-ord('a')
if n%2 == i:
ta=al.pop() # take from left list
else:
ta=ar[0] # take from right list
ar=ar[1:]
#if (n/2)%2 == j:
if n%2 == j:
ar.append(ta) # append to right list
else:
al.insert(0,ta) # insert in left list
return (al,ar)
print ' ',al,ar
for c in k:
(al,ar) = round(c,al,ar)
print c,al,ar
[toc] | [prev] | [next] | [standalone]
| From | Max <maxturv26@gmx.net> |
|---|---|
| Date | 2021-10-02 16:25 +0200 |
| Message-ID | <sj9q5b$lc3$1@gioia.aioe.org> |
| In reply to | #50295 |
On 02.10.21 13:28, wizzofozz wrote:
> Op 2-10-2021 om 12:18 schreef Max:
>
>>
>> Ok. This isn't the only possible order in which to sort the letters.
>> Some steps are forced, but not all. E.g., for the 3rd b one could
>> either move the L to the right or the P to the left. This creates a
>> tree. Have to dig into this later.
>>
>
> I just tested with an implementation which uses a "left list" and "right
> list". I think this slightly different
I like this thinking.
>
> Some code:
>
Nice. I hope you are no Python purist, as I slaughtered your code and
hacked it into this abomination. It doesn't take any arguments.
----------------------------------
#!/usr/bin/python
import sys
solString = "WVUPMOABCDEFGXYZNLKQRSTJIH"
keyLength=16
sol=[c for c in solString]
al=[c for c in "ABCDEFGHIJKLM"]
ar=[c for c in "NOPQRSTUVWXYZ"]
#Run a recursion over all steps of the algorithm that might lead to the
correct solution
def possibleSteps(key, al, ar, ctr):
if (ctr < keyLength):
for i1 in range(0,2):
for i2 in range(0,2):
(bl, br) = round(i1, i2, al, ar)
if (
("".join(sol).find("".join(bl)[:2]) != -1) and
("".join(sol).find("".join(br)[-2:]) != -1) ):
possibleSteps(key + str(i1) +
str(i2), bl, br, ctr+1)
else:
if (("".join(al)+"".join(ar)) == "".join(sol)):
print key #key in binary
#Make key into 4 readable letters
key2=""
while (len(key) > 0):
if (key[:2] == "00"):
key2 = key2 + "a"
elif (key[:2] == "01"):
key2 = key2 + "b"
elif (key[:2] == "10"):
key2 = key2 + "c"
elif (key[:2] == "11"):
key2 = key2 + "d"
key=key[2:]
print key2
return
def round(n1, n2, al, ar):
cl = al[:]
cr = ar[:]
if n1%2 == 0:
ta=cl.pop() # take from left list
else:
ta=cr[0] # take from right list
cr=cr[1:]
#if (n/2)%2 == j:
if n2%2 == 1:
cr.append(ta) # append to right list
else:
cl.insert(0,ta) # insert in left list
return (cl,cr)
print solString
print
possibleSteps("", al, ar, 0)
-------------------------------------
Yet, this gives us all possible combinations that would result in the
final cipher, being:
11100001011011111111010101101010
11100001011011111111010110011010
11100001011011111111010110100110
11100001011011111111010110101001
11100001011011111111011001011010
11100001011011111111011001100110
11100001011011111111011001101001
11100001011011111111011010010110
11100001011011111111011010011001
11100001011011111111011010100101
11100001011011111111100101011010
11100001011011111111100101100110
11100001011011111111100101101001
11100001011011111111100110010110
11100001011011111111100110011001
11100001011011111111100110100101
11100001011011111111101001010110
11100001011011111111101001011001
11100001011011111111101001100101
11100001011011111111101010010101
11100001100111111111010101101010
11100001100111111111010110011010
11100001100111111111010110100110
11100001100111111111010110101001
11100001100111111111011001011010
11100001100111111111011001100110
11100001100111111111011001101001
11100001100111111111011010010110
11100001100111111111011010011001
11100001100111111111011010100101
11100001100111111111100101011010
11100001100111111111100101100110
11100001100111111111100101101001
11100001100111111111100110010110
11100001100111111111100110011001
11100001100111111111100110100101
11100001100111111111101001010110
11100001100111111111101001011001
11100001100111111111101001100101
11100001100111111111101010010101
11100010010111111111010101101010
11100010010111111111010110011010
11100010010111111111010110100110
11100010010111111111010110101001
11100010010111111111011001011010
11100010010111111111011001100110
11100010010111111111011001101001
11100010010111111111011010010110
11100010010111111111011010011001
11100010010111111111011010100101
11100010010111111111100101011010
11100010010111111111100101100110
11100010010111111111100101101001
11100010010111111111100110010110
11100010010111111111100110011001
11100010010111111111100110100101
11100010010111111111101001010110
11100010010111111111101001011001
11100010010111111111101001100101
11100010010111111111101010010101
or, for readability, condensed to a 4-letter alphabet
dcabbcddddbbbccc
dcabbcddddbbcbcc
dcabbcddddbbccbc
dcabbcddddbbcccb
dcabbcddddbcbbcc
dcabbcddddbcbcbc
dcabbcddddbcbccb
dcabbcddddbccbbc
dcabbcddddbccbcb
dcabbcddddbcccbb
dcabbcddddcbbbcc
dcabbcddddcbbcbc
dcabbcddddcbbccb
dcabbcddddcbcbbc
dcabbcddddcbcbcb
dcabbcddddcbccbb
dcabbcddddccbbbc
dcabbcddddccbbcb
dcabbcddddccbcbb
dcabbcddddcccbbb
dcabcbddddbbbccc
dcabcbddddbbcbcc
dcabcbddddbbccbc
dcabcbddddbbcccb
dcabcbddddbcbbcc
dcabcbddddbcbcbc
dcabcbddddbcbccb
dcabcbddddbccbbc
dcabcbddddbccbcb
dcabcbddddbcccbb
dcabcbddddcbbbcc
dcabcbddddcbbcbc
dcabcbddddcbbccb
dcabcbddddcbcbbc
dcabcbddddcbcbcb
dcabcbddddcbccbb
dcabcbddddccbbbc
dcabcbddddccbbcb
dcabcbddddccbcbb
dcabcbddddcccbbb
dcacbbddddbbbccc
dcacbbddddbbcbcc
dcacbbddddbbccbc
dcacbbddddbbcccb
dcacbbddddbcbbcc
dcacbbddddbcbcbc
dcacbbddddbcbccb
dcacbbddddbccbbc
dcacbbddddbccbcb
dcacbbddddbcccbb
dcacbbddddcbbbcc
dcacbbddddcbbcbc
dcacbbddddcbbccb
dcacbbddddcbcbbc
dcacbbddddcbcbcb
dcacbbddddcbccbb
dcacbbddddccbbbc
dcacbbddddccbbcb
dcacbbddddccbcbb
dcacbbddddcccbbb
Now, we just have to sieve the one that reeks of "babbylevelsoeasy"...
[toc] | [prev] | [next] | [standalone]
| From | wizzofozz <oxxxxxxxxxxxs@gmail.com> |
|---|---|
| Date | 2021-10-02 17:25 +0200 |
| Message-ID | <sj9tl8$8he$1@dont-email.me> |
| In reply to | #50297 |
Op 2-10-2021 om 16:25 schreef Max:
> On 02.10.21 13:28, wizzofozz wrote:
>> Op 2-10-2021 om 12:18 schreef Max:
>>
>>>
>>> Ok. This isn't the only possible order in which to sort the letters.
>>> Some steps are forced, but not all. E.g., for the 3rd b one could
>>> either move the L to the right or the P to the left. This creates a
>>> tree. Have to dig into this later.
>>>
>>
>> I just tested with an implementation which uses a "left list" and
>> "right list". I think this slightly different
>
> I like this thinking.
>
>>
>> Some code:
>>
>
> Nice. I hope you are no Python purist, as I slaughtered your code and
> hacked it into this abomination. It doesn't take any arguments.
I'm certainly not a Python purist, and cool that you used my code. I'll
have to study yours a bit to see how it works, but I think I understand
what you're doing. I added to your code, a little loop to check all the
permutations of the characters which were missing for the mapping.
Interestingly, only solutions are found for the one we assumed correct
(I think I implemented the loop correctly, code at the end of the post).
I glanced over your list to see if there was an obvious
"babbylevelsoeasy" candidate but none found yet. Tonight I'll be doing
other things, but I'll keep an eye out for new posts.
Output of your search within the "permutations loop":
WVUPMOABCDEFGXYHJLKQRSTZIN
WVUPMOABCDEFGXYHJLKQRSTNIZ
WVUPMOABCDEFGXYHZLKQRSTJIN
WVUPMOABCDEFGXYHZLKQRSTNIJ
WVUPMOABCDEFGXYHNLKQRSTJIZ
WVUPMOABCDEFGXYHNLKQRSTZIJ
WVUPMOABCDEFGXYJHLKQRSTZIN
WVUPMOABCDEFGXYJHLKQRSTNIZ
WVUPMOABCDEFGXYJZLKQRSTHIN
WVUPMOABCDEFGXYJZLKQRSTNIH
WVUPMOABCDEFGXYJNLKQRSTHIZ
WVUPMOABCDEFGXYJNLKQRSTZIH
WVUPMOABCDEFGXYZHLKQRSTJIN
WVUPMOABCDEFGXYZHLKQRSTNIJ
WVUPMOABCDEFGXYZJLKQRSTHIN
WVUPMOABCDEFGXYZJLKQRSTNIH
WVUPMOABCDEFGXYZNLKQRSTHIJ
WVUPMOABCDEFGXYZNLKQRSTJIH
11100001011011111111010101101010
dcabbcddddbbbccc
11100001011011111111010110011010
dcabbcddddbbcbcc
11100001011011111111010110100110
dcabbcddddbbccbc
11100001011011111111010110101001
dcabbcddddbbcccb
11100001011011111111011001011010
dcabbcddddbcbbcc
11100001011011111111011001100110
dcabbcddddbcbcbc
11100001011011111111011001101001
dcabbcddddbcbccb
11100001011011111111011010010110
dcabbcddddbccbbc
11100001011011111111011010011001
dcabbcddddbccbcb
11100001011011111111011010100101
dcabbcddddbcccbb
11100001011011111111100101011010
dcabbcddddcbbbcc
11100001011011111111100101100110
dcabbcddddcbbcbc
11100001011011111111100101101001
dcabbcddddcbbccb
11100001011011111111100110010110
dcabbcddddcbcbbc
11100001011011111111100110011001
dcabbcddddcbcbcb
11100001011011111111100110100101
dcabbcddddcbccbb
11100001011011111111101001010110
dcabbcddddccbbbc
11100001011011111111101001011001
dcabbcddddccbbcb
11100001011011111111101001100101
dcabbcddddccbcbb
11100001011011111111101010010101
dcabbcddddcccbbb
11100001100111111111010101101010
dcabcbddddbbbccc
11100001100111111111010110011010
dcabcbddddbbcbcc
11100001100111111111010110100110
dcabcbddddbbccbc
11100001100111111111010110101001
dcabcbddddbbcccb
11100001100111111111011001011010
dcabcbddddbcbbcc
11100001100111111111011001100110
dcabcbddddbcbcbc
11100001100111111111011001101001
dcabcbddddbcbccb
11100001100111111111011010010110
dcabcbddddbccbbc
11100001100111111111011010011001
dcabcbddddbccbcb
11100001100111111111011010100101
dcabcbddddbcccbb
11100001100111111111100101011010
dcabcbddddcbbbcc
11100001100111111111100101100110
dcabcbddddcbbcbc
11100001100111111111100101101001
dcabcbddddcbbccb
11100001100111111111100110010110
dcabcbddddcbcbbc
11100001100111111111100110011001
dcabcbddddcbcbcb
11100001100111111111100110100101
dcabcbddddcbccbb
11100001100111111111101001010110
dcabcbddddccbbbc
11100001100111111111101001011001
dcabcbddddccbbcb
11100001100111111111101001100101
dcabcbddddccbcbb
11100001100111111111101010010101
dcabcbddddcccbbb
11100010010111111111010101101010
dcacbbddddbbbccc
11100010010111111111010110011010
dcacbbddddbbcbcc
11100010010111111111010110100110
dcacbbddddbbccbc
11100010010111111111010110101001
dcacbbddddbbcccb
11100010010111111111011001011010
dcacbbddddbcbbcc
11100010010111111111011001100110
dcacbbddddbcbcbc
11100010010111111111011001101001
dcacbbddddbcbccb
11100010010111111111011010010110
dcacbbddddbccbbc
11100010010111111111011010011001
dcacbbddddbccbcb
11100010010111111111011010100101
dcacbbddddbcccbb
11100010010111111111100101011010
dcacbbddddcbbbcc
11100010010111111111100101100110
dcacbbddddcbbcbc
11100010010111111111100101101001
dcacbbddddcbbccb
11100010010111111111100110010110
dcacbbddddcbcbbc
11100010010111111111100110011001
dcacbbddddcbcbcb
11100010010111111111100110100101
dcacbbddddcbccbb
11100010010111111111101001010110
dcacbbddddccbbbc
11100010010111111111101001011001
dcacbbddddccbbcb
11100010010111111111101001100101
dcacbbddddccbcbb
11100010010111111111101010010101
dcacbbddddcccbbb
WVUPMOABCDEFGXYNHLKQRSTJIZ
WVUPMOABCDEFGXYNHLKQRSTZIJ
WVUPMOABCDEFGXYNJLKQRSTHIZ
WVUPMOABCDEFGXYNJLKQRSTZIH
WVUPMOABCDEFGXYNZLKQRSTHIJ
WVUPMOABCDEFGXYNZLKQRSTJIH
Code:
#!/usr/bin/python
import sys
from itertools import permutations
#WVUPMOABCDEFGXY??LKQRST?I?
#solString = "WVUPMOABCDEFGXYZNLKQRSTJIH"
keyLength=16
sol=[]
al=[]
ar=[]
def solInit(solString):
sol=[c for c in solString]
al=[c for c in "ABCDEFGHIJKLM"]
ar=[c for c in "NOPQRSTUVWXYZ"]
return (sol,al,ar)
#Run a recursion over all steps of the algorithm that might lead to the
correct solution
def possibleSteps(key, al, ar, ctr):
if (ctr < keyLength):
for i1 in range(0,2):
for i2 in range(0,2):
(bl, br) = round(i1, i2, al, ar)
if (
("".join(sol).find("".join(bl)[:2]) != -1) and
("".join(sol).find("".join(br)[-2:]) != -1) ):
possibleSteps(key + str(i1) +
str(i2), bl, br, ctr+1)
else:
if (("".join(al)+"".join(ar)) == "".join(sol)):
print key #key in binary
#Make key into 4 readable letters
key2=""
while (len(key) > 0):
if (key[:2] == "00"):
key2 = key2 + "a"
elif (key[:2] == "01"):
key2 = key2 + "b"
elif (key[:2] == "10"):
key2 = key2 + "c"
elif (key[:2] == "11"):
key2 = key2 + "d"
key=key[2:]
print key2
return
def round(n1, n2, al, ar):
cl = al[:]
cr = ar[:]
if n1%2 == 0:
ta=cl.pop() # take from left list
else:
ta=cr[0] # take from right list
cr=cr[1:]
#if (n/2)%2 == j:
if n2%2 == 1:
cr.append(ta) # append to right list
else:
cl.insert(0,ta) # insert in left list
return (cl,cr)
for i in permutations(['H','J','Z','N']):
solString = "WVUPMOABCDEFGXY"+i[0]+i[1]+"LKQRST"+i[2]+"I"+i[3]
print solString
(sol,al,ar) = solInit(solString)
print
possibleSteps("", al, ar, 0)
Ozz
[toc] | [prev] | [next] | [standalone]
| From | wizzofozz <oxxxxxxxxxxxs@gmail.com> |
|---|---|
| Date | 2021-10-02 12:28 +0200 |
| Message-ID | <sj9c7o$h63$1@dont-email.me> |
| In reply to | #50288 |
Op 2-10-2021 om 04:20 schreef Max: > > What if this algorithm works "inside out", taking single letters from > the middle of the alphabet and deciding to put it at the beginning oŕ at > the end? That would also explain, that the backwards-stretch "WVU" is at > the beginning, not at the end of the key. > <snip> > > This looks promising. > Very nice, Max. I don't think I would have thought of that. > > "b" means: take the right of the two "inner letters" and put it to the > right end, this means: > > b : right => right > a : right => left What I learn from this, is how many keybits are wasted. For every step you only need 2 bits, so for the whole thing you would need 32 bits. The given key is 16 chars long which I think would be 16*5 bits (5 bit for a number between 0..26). So more than half are wasted. > > I don't see an easy mapping here and it's too late for a tricky one. > Maybe tomorrow. Maybe you see something in this that I don't see. > I tried a couple of things with combining some bits of the position of each keybyte with the keybyte itself. But that gives me nothing (I could be mistaken of course). Maybe I'll try later today to check if somehow the function of a keybyte depends on the previous one. I also still consider the possibility that his algorithm does something with the chunks at each step, which makes it seem that the next same keybyte behaves differently (if that makes sense). > > I'm still thinking along these lines. My current 'swap' algorithm > > generates stuff like WVUTSRQPONMYXZABCDEFGLKJIH, which is pretty close > > [...] > > Not bad. The code is simple enough and the result is indeed pretty > close. Yet, for now, I tend towards my approach. I agree, yours is the better approach. cheers Ozz
[toc] | [prev] | [next] | [standalone]
| From | Leo <usenet@gkbrk.com> |
|---|---|
| Date | 2021-10-02 10:42 -0500 |
| Message-ID | <JfadnZb9g-VW4MX8nZ2dnUU78QudnZ2d@giganews.com> |
| In reply to | #50288 |
On Sat, 02 Oct 2021 04:20:22 +0200, Max wrote: Hi all, Sorry about the radio silence, I've been AFK for a few days since I'm on holiday. > What if this algorithm works "inside out", taking single letters from > the middle of the alphabet and deciding to put it at the beginning oŕ at > the end? That would also explain, that the backwards-stretch "WVU" is at > the beginning, not at the end of the key. This is exactly right. For each character of the key, we take letters from the middle of the alphabet and put it on the beginning or the end. For the first level of the reddit post, each key character results in one of these moves. Yes, it wastes a lot of key material, it was done this way to make it obvious to people that the alphabet shifts for each key character. > This looks promising. > > That would also mean that the full mapping is > > WVUPMOABCDEFGXYZNLKQRSTJIH > > which is also consistent with the letters we know. Seems right, the ciphertext I get when I encrypt the alphabet is WVUPMOABCDEFGXYZNLKQRSTJIH. > So, the question remains: When will I take a letter from the right vs. > the left side and when do I put it to the right or to the left? I don't think there is a distinction like this. Middle is just 26 / 2 as an integer. It might have been better to pick right and put it on the left and vice versa, but that is not done. So for each character, index 13 (0-indexed) is popped from the alphabet and either inserted to the beginning or the end. -- Leo
[toc] | [prev] | [next] | [standalone]
| From | Max <maxturv26@gmx.net> |
|---|---|
| Date | 2021-10-02 18:13 +0200 |
| Message-ID | <sja0fp$1mr4$1@gioia.aioe.org> |
| In reply to | #50302 |
On 02.10.21 17:42, Leo wrote: > On Sat, 02 Oct 2021 04:20:22 +0200, Max wrote: > > Hi all, > > Sorry about the radio silence, I've been AFK for a few days since I'm > on holiday. > >> What if this algorithm works "inside out", taking single letters from >> the middle of the alphabet and deciding to put it at the beginning oŕ at >> the end? That would also explain, that the backwards-stretch "WVU" is at >> the beginning, not at the end of the key. > > This is exactly right. For each character of the key, we take letters > from the middle of the alphabet and put it on the beginning or the > end. > > For the first level of the reddit post, each key character results in > one of these moves. Yes, it wastes a lot of key material, it was done > this way to make it obvious to people that the alphabet shifts for > each key character. > >> This looks promising. >> >> That would also mean that the full mapping is >> >> WVUPMOABCDEFGXYZNLKQRSTJIH >> >> which is also consistent with the letters we know. > > Seems right, the ciphertext I get when I encrypt the alphabet is > WVUPMOABCDEFGXYZNLKQRSTJIH. > >> So, the question remains: When will I take a letter from the right vs. >> the left side and when do I put it to the right or to the left? > > I don't think there is a distinction like this. Middle is just 26 / 2 > as an integer. It might have been better to pick right and put it on > the left and vice versa, but that is not done. > > So for each character, index 13 (0-indexed) is popped from the > alphabet and either inserted to the beginning or the end. > Oh boy, that's embarrassing. Thanks for pointing out that you always take the character at position 13. Once you see it, it's obvious (of course), but I might have digged a really deep tunnel into a completely different direction. Cheers, Max
[toc] | [prev] | [next] | [standalone]
| From | wizzofozz <oxxxxxxxxxxxs@gmail.com> |
|---|---|
| Date | 2021-10-03 12:27 +0200 |
| Message-ID | <sjc0ik$dqt$1@dont-email.me> |
| In reply to | #50306 |
Op 2-10-2021 om 18:13 schreef Max: > On 02.10.21 17:42, Leo wrote: >> On Sat, 02 Oct 2021 04:20:22 +0200, Max wrote: >> >> Hi all, >> >> Sorry about the radio silence, I've been AFK for a few days since I'm >> on holiday. >> >>> What if this algorithm works "inside out", taking single letters from >>> the middle of the alphabet and deciding to put it at the beginning oŕ at >>> the end? That would also explain, that the backwards-stretch "WVU" is at >>> the beginning, not at the end of the key. >> >> This is exactly right. For each character of the key, we take letters >> from the middle of the alphabet and put it on the beginning or the >> end. >> >>> So, the question remains: When will I take a letter from the right vs. >>> the left side and when do I put it to the right or to the left? >> >> I don't think there is a distinction like this. Middle is just 26 / 2 >> as an integer. It might have been better to pick right and put it on >> the left and vice versa, but that is not done. >> >> So for each character, index 13 (0-indexed) is popped from the >> alphabet and either inserted to the beginning or the end. >> > > Oh boy, that's embarrassing. Thanks for pointing out that you always > take the character at position 13. Once you see it, it's obvious (of > course), but I might have digged a really deep tunnel into a completely > different direction. I will embarrass myself a bit more, by admitting I still don't see it. I understand taking a letter from position 13 and placing it either to beginning or end. But based on what is that decision (begin/end) made? I tested (again) a couple of methods with alternating counter (which cannot be correct anyway because of e.g. 'WVU'), based on lsb of keybyte etc, but I don't get the correct permutation (I also understand it does not matter for 'cracking' the babbylevel ciphertext, but now I'm obsessed with it). Ozz
[toc] | [prev] | [next] | [standalone]
| From | Max <maxturv26@gmx.net> |
|---|---|
| Date | 2021-10-03 18:02 +0200 |
| Message-ID | <sjck63$np9$1@gioia.aioe.org> |
| In reply to | #50333 |
On 03.10.21 12:27, wizzofozz wrote: [...] > > I will embarrass myself a bit more, by admitting I still don't see it. > I understand taking a letter from position 13 and placing it either to > beginning or end. But based on what is that decision (begin/end) made? That part I also don't know, yet. But we could have wasted so much time, trying to get the input order into this as well. So I am glad about Leo's hint. So, the correct sorting order is (right = 1, left = 0) b = 1 -> 1 a = 0 -> 0 b = 1 -> 0 b = 1 -> 1 y = 24 -> 0 l = 11 -> 1 e = 4 -> 1 v = 21 -> 1 e = 4 -> 1 l = 11 -> 1 s = 18 -> 0 o = 14 -> 1 e = 4 - > 0 a = 0 -> 1 s = 18 -> 0 y = 24 -> 1 I think, this we can take as certain. The remaining question is, how do we get from the keyword to this bit-order, right? What information could the keyword/a letter in the keyword contain? 1. letter-value mod 2 2. "Is the letter-value higher (or equal) of lower (or equal) than the preceding one?" 3. (The XOR-result or difference of some letter-values) mod 2 4. How many times has a letter appeared in the keyword before? 5. Position of a letter in the key-word Can you think of anything else? I guess, it will be some combination of some of these and in his "harder" ciphers, Leo will add letters from the plaintext to the mix as well. What could a letter from the key word encode? - The position (left or right) - A switch of the position (switch or don't switch) It's also possible that the keyword gets permuted/modified, as well, isn't it? But I would leave that out for now (it's still babby level). > I tested (again) a couple of methods with alternating counter (which > cannot be correct anyway because of e.g. 'WVU'), based on lsb of keybyte > etc, but I don't get the correct permutation (I also understand it does > not matter for 'cracking' the babbylevel ciphertext, > but now I'm obsessed with it). Same here. :-) I've been looking for a decent hand-cipher in the past (applicable by hand for reasonably small amounts of plaintext, but hard to break, even with computer analysis). This may be a candidate for this. We'll see. > > Ozz >
[toc] | [prev] | [next] | [standalone]
Page 1 of 2 [1] 2 Next page →
Back to top | Article view | sci.crypt
csiph-web