@Kamil please post your address, i’ll send you small bonus 
2 Likes
Yes, the “main” or “seed” account key as you put it (you could extract all media directly from that; I did, but still went through all of them, because I didn’t realize it was a mistake 
). But I’m talking about the key in audio - the very same key is also in golly.
Just take the one from my profile. Thank you, that is very generous of you.
as i see in initial design audio private key is a first part of level 4. We should figure out how it connected to cellular automaton and get second part. Only after that we receive access to last level 5.
warm->brain
brain->work
work->life
life->life
life->sense
sense->jackpot
yup exactly, life was a two stage, so there was “same” key in life to give tip, how to get to “second” key
@deleted_user_1, @gimre Please take a look at this: https://en.wikipedia.org/wiki/Padding_(cryptography)#PKCS7; In nem-library, PKCS #5/7 padding strategy from crypto-js/cipher-core.js is used during decrypting the buffer. Last byte from decrypted data is interpreted as number of padding bytes and that number of bytes is then cut off the returned buffer. If the padding information is not stored on the chain (I suppose it is not, right, @gimre? … it would eat up to N bytes), then this routine either can not be used to decrypt the data, or a workaround has to be implemented. I can imagine pretty much what I used to get the audio - append 256 bytes of garbage (unknown part of it will be removed by the unpadding routine) and after decrypting fix the length (encrypted length - 24?). Or is there a better way?
Edit: In nem-library:
…
974 payload => 1024 bytes (2 bytes padding)
975 payload => 1024 bytes (1 byte padding)
976 payload => 1040 bytes (16 bytes padding)
…
976 bytes of payload translates into 1040 bytes of encrypted data, where last 16 bytes is padding. This doesn’t fit into maximum of 1024 bytes of payload for NEM messages. So in this case, it was stored without padding. The decrypting routines then have no way to recognize this (versus i.e. correctly formatted message with length 960 bytes + 16 bytes of padding, which also translates into 1024 bytes payload).
IMO all NEM libraries/wrappers we have should work the same documented way (whatever encrypted in one should be decryptable in all others; otherwise there will be confusion). And someone should directively decide how; i.e. limit the payload to 975 bytes?
If @gimre didn’t use any “standard nem” library, but “own” solution (or deliberately omitted the padding), then all can even be ok. So … what did you use?
cool one
custom
nanowallet limits encrypted content to 960 bytes
1 Like
So here is the game’s scenario
level 1
Just open wallet and decrypt the message you get private key for level 2
level 2
Next encrypted message is not plain text, it is brainfuck programm which you need to run to get next private key
level 3
The most complicated level see info above
level 4
After decoding message you get the configuration of RLE pattern. http://golly.sourceforge.net/webapp/golly.html will help.
Notice that pattern has square size and two states. Assume that black cell is 0 and white one is 1 and then convert it to hex.
1st state get you the same private key as used to open this level. 2nd state allows go further
level 5
there is an png image in message. Image contains final private key encrypted by Nemeth Braille Code.
we glad to invite everybody (especially @gimre ) to next NEM riddles. it will be not such NEM connected but curious, we hope.