Computer Nerd Kev <not@telling.you.invalid> wrote:

I've got long strings like this from URLs (percent-encoded
characters have been decoded):

SdADygkIiM8ED8ZK/ZfkxwbHEgOXnsgKzQcYtq2j3L1HN6OYvET8PwvO2gpCCv4Bp4vIGLwLFN3dDQABOjWT0gVI/EtBlNUIObwLFNnU90IK/gCs2QQzBzhEz8sNAAdBPpmM+T0KRgudx88HxzsFnpjGQs8PBp+fEAvQCgCZnsdKzQz+lpbIBPj7CQ==

I believe they might be encrypted strings containing one or more
known fields, probably including a known ten digit number
(1409518286 in that case). They might also be hashes, but I think
it's unlikely.

I got a copy of the PHP code. Turns out it's a "transposition
cipher" which adds different numbers to the ASCII value of each
character in sequence.

To decrypt, first the string is base64 decoded. Then the first
character's ASCII value has the ASCII value of the first character
in the password subtracted from it, as well as fixed value. Then
for the next encrypted string character the next password character
is subtracted along with the fixed value, and so on, with the
password characters repeating from the start when they run out.
Sure enough that decrypted string contains "1409518286" and other
info.

Very simple, but I still wonder what tools are available to
brute-force that without knowing what sort of encryption method has
been used?

--
__ __
#_ < |\| |< _#

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Computer Nerd Kev <not@telling.you.invalid> wrote:

Computer Nerd Kev <not@telling.you.invalid> wrote:

I've got long strings like this from URLs (percent-encoded
characters have been decoded):

SdADygkIiM8ED8ZK/ZfkxwbHEgOXnsgKzQcYtq2j3L1HN6OYvET8PwvO2gpCCv4Bp4vIGLwLFN3dDQABOjWT0gVI/EtBlNUIObwLFNnU90IK/gCs2QQzBzhEz8sNAAdBPpmM+T0KRgudx88HxzsFnpjGQs8PBp+fEAvQCgCZnsdKzQz+lpbIBPj7CQ==

I believe they might be encrypted strings containing one or more
known fields, probably including a known ten digit number
(1409518286 in that case). They might also be hashes, but I think
it's unlikely.

I got a copy of the PHP code. Turns out it's a "transposition
cipher" which adds different numbers to the ASCII value of each
character in sequence.

Also called the Ceasar cipher:

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

Very simple,

Yes, that it is, and very weak against attack.

but I still wonder what tools are available to brute-force that
without knowing what sort of encryption method has been used?

Without working out which encryption algorithm, there are not a lot of
tools (besides asking one of these new AI's to "try everything").
Brute force has a somewhat narrow definition in the cryptography
community of trying all the possible keys until the correct key is
found -- which has an unstated dependency of "for the known encryption algorithm used". So you can't "brute force", per the usual crypto
meaning, until after you know (or have a good idea of) the algorithm
used.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Rich <rich@example.invalid> wrote:

Computer Nerd Kev <not@telling.you.invalid> wrote:

Computer Nerd Kev <not@telling.you.invalid> wrote:

I've got long strings like this from URLs (percent-encoded
characters have been decoded):

SdADygkIiM8ED8ZK/ZfkxwbHEgOXnsgKzQcYtq2j3L1HN6OYvET8PwvO2gpCCv4Bp4vIGLwLFN3dDQABOjWT0gVI/EtBlNUIObwLFNnU90IK/gCs2QQzBzhEz8sNAAdBPpmM+T0KRgudx88HxzsFnpjGQs8PBp+fEAvQCgCZnsdKzQz+lpbIBPj7CQ==

I believe they might be encrypted strings containing one or more
known fields, probably including a known ten digit number
(1409518286 in that case). They might also be hashes, but I think
it's unlikely.

I got a copy of the PHP code. Turns out it's a "transposition
cipher" which adds different numbers to the ASCII value of each
character in sequence.

Also called the Ceasar cipher:

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

Almost, but unlike the description there, the number of shifted
positions varies for each character in the encrypted string, since
the shift length depends on the ASCII value of each character in the
password. That means you couldn't simply shift the whole string all
the possible lengths until the string "1409518286" was found in the
result. Instead you'd have all the possible combinations of
independently shifted characters = 128 (ASCII character set) to the
power of the number of characters in the string. In this case
128^182 = 3.25e+383, which is ridiculous, but some shortcuts would
be possible, and probably many more than I can immediately guess.

Very simple,

Yes, that it is, and very weak against attack.

Probably, but a lot stronger than the Ceasar Cipher by my
reckoning.

but I still wonder what tools are available to brute-force that
without knowing what sort of encryption method has been used?

Without working out which encryption algorithm, there are not a lot of
tools (besides asking one of these new AI's to "try everything").
Brute force has a somewhat narrow definition in the cryptography
community of trying all the possible keys until the correct key is
found -- which has an unstated dependency of "for the known encryption algorithm used". So you can't "brute force", per the usual crypto
meaning, until after you know (or have a good idea of) the algorithm
used.

Well the brute force approach I had in mind was to try brute
force using all the different known ciphers in turn, from simplest
onwards, with this cipher being tried not far after the Ceasar
Cipher, though very possibly not before some infeasible number of
possibilities was reached, given the length of the string. That it
was also base64 encoded would've thrown a spanner in the works, but
I'm thinking there may also be some smarter general-purpose
cracking approaches that could be used instead of pure brute-force.
You don't know if you don't ask...

--
__ __
#_ < |\| |< _#

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Computer Nerd Kev <not@telling.you.invalid> wrote:

Rich <rich@example.invalid> wrote:

Computer Nerd Kev <not@telling.you.invalid> wrote:

Computer Nerd Kev <not@telling.you.invalid> wrote:

I've got long strings like this from URLs (percent-encoded
characters have been decoded):

SdADygkIiM8ED8ZK/ZfkxwbHEgOXnsgKzQcYtq2j3L1HN6OYvET8PwvO2gpCCv4Bp4vIGLwLFN3dDQABOjWT0gVI/EtBlNUIObwLFNnU90IK/gCs2QQzBzhEz8sNAAdBPpmM+T0KRgudx88HxzsFnpjGQs8PBp+fEAvQCgCZnsdKzQz+lpbIBPj7CQ==

I believe they might be encrypted strings containing one or more
known fields, probably including a known ten digit number
(1409518286 in that case). They might also be hashes, but I think
it's unlikely.

I got a copy of the PHP code. Turns out it's a "transposition
cipher" which adds different numbers to the ASCII value of each
character in sequence.

Also called the Ceasar cipher:

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

Almost, but unlike the description there, the number of shifted
positions varies for each character in the encrypted string, since
the shift length depends on the ASCII value of each character in the password. That means you couldn't simply shift the whole string all
the possible lengths until the string "1409518286" was found in the
result. Instead you'd have all the possible combinations of
independently shifted characters = 128 (ASCII character set) to the
power of the number of characters in the string. In this case
128^182 = 3.25e+383, which is ridiculous, but some shortcuts would

^^^^^^^
First thing I need to do is learn how to count characters in a
string (well actually I did, but forgot them number before I typed
it). Should've been:

128^188 = 1.43e+396

But it's base64 encoded, so if you don't know that, then multiply
that number by the number of different possible byte/character
encodings you'd have to try as well. If there isn't a smarter
approach.

--
__ __
#_ < |\| |< _#

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

I've got long strings like this from URLs (percent-encoded
characters have been decoded):

SdADygkIiM8ED8ZK/ZfkxwbHEgOXnsgKzQcYtq2j3L1HN6OYvET8PwvO2gpCCv4Bp4vIGLwLFN3dDQABOjWT0gVI/EtBlNUIObwLFNnU90IK/gCs2QQzBzhEz8sNAAdBPpmM+T0KRgudx88HxzsFnpjGQs8PBp+fEAvQCgCZnsdKzQz+lpbIBPj7CQ==

I believe they might be encrypted strings containing one or more
known fields, probably including a known ten digit number
(1409518286 in that case). They might also be hashes, but I think
it's unlikely.

Are there any simple Linux tools that can help identify and crack
the algorithm by checking combinations of the known strings that
it's likely to contain? Similar to what John The Ripper
does for password hashes by checking against dictionaries of
common passwords. Then I could write code to decrypt the other
strings.

I think the PHP scripts generating the strings were first written
well over twenty years ago, so I'm guessing it's nothing all that sophisticated.

--
__ __
#_ < |\| |< _#

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Computer Nerd Kev <not@telling.you.invalid> wrote:

Rich <rich@example.invalid> wrote:

Computer Nerd Kev <not@telling.you.invalid> wrote:

Computer Nerd Kev <not@telling.you.invalid> wrote:

I've got long strings like this from URLs (percent-encoded
characters have been decoded):

SdADygkIiM8ED8ZK/ZfkxwbHEgOXnsgKzQcYtq2j3L1HN6OYvET8PwvO2gpCCv4Bp4vIGLwLFN3dDQABOjWT0gVI/EtBlNUIObwLFNnU90IK/gCs2QQzBzhEz8sNAAdBPpmM+T0KRgudx88HxzsFnpjGQs8PBp+fEAvQCgCZnsdKzQz+lpbIBPj7CQ==

I believe they might be encrypted strings containing one or more
known fields, probably including a known ten digit number
(1409518286 in that case). They might also be hashes, but I think
it's unlikely.

I got a copy of the PHP code. Turns out it's a "transposition
cipher" which adds different numbers to the ASCII value of each
character in sequence.

Also called the Ceasar cipher:

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

Almost, but unlike the description there, the number of shifted
positions varies for each character in the encrypted string, since
the shift length depends on the ASCII value of each character in the password. That means you couldn't simply shift the whole string all
the possible lengths until the string "1409518286" was found in the
result. Instead you'd have all the possible combinations of
independently shifted characters = 128 (ASCII character set) to the
power of the number of characters in the string. In this case
128^182 = 3.25e+383, which is ridiculous, but some shortcuts would
be possible, and probably many more than I can immediately guess.

There was a crank in sci.crypt some years back purporting to have an unbreakable cipher that turned out to be a close variant to your
description above. His cipher didn't last long once one of the few
members of sci.crypt who "knew what they were doing" began to attack
it.

Much later (only a couple years ago now) one of the regulars posted a
toy algorithm he called SCOS (Sci Crypt Open Secret). It was intended
to be a moderate effort one to attack to give folks something to do in
their spare time. Quite some number of regulars cracked it in due
time. Although the author of the cipher did offer up arbitrary
encrypted requests (you ask for something to be encrypted, he'd return
you the encrypted variant) which was helpful in deducing the algorithm.
It turned out to be a similar "shifting-shift" type cipher as you
describe.

Very simple,

Yes, that it is, and very weak against attack.

Probably, but a lot stronger than the Ceasar Cipher by my
reckoning.

If the above pair on sci.crypt are any indication, it is not much
stronger than Ceasar.

Well the brute force approach I had in mind was to try brute
force using all the different known ciphers in turn, from simplest
onwards, with this cipher being tried not far after the Ceasar
Cipher, though very possibly not before some infeasible number of possibilities was reached, given the length of the string. That it
was also base64 encoded would've thrown a spanner in the works, but
I'm thinking there may also be some smarter general-purpose
cracking approaches that could be used instead of pure brute-force.
You don't know if you don't ask...

The successful cracks of SCOS looked for patterns in the output, and
those patterns provided enough clues to eventually deduce the
algorithm.

Granted, everyone had more than one ~ 100 character long URL to work
with, but simply changing the Ceasar rotation with each character isn't
going to make ceasar a replacement for DES or AES by any measure. And changing it based on the ascii value of the character being encoded
still leaves behind the underlying frequency components of the
character usage in the plaintext, which helps to crack the cipher open.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Computer Nerd Kev <not@telling.you.invalid> wrote:

Computer Nerd Kev <not@telling.you.invalid> wrote:

Rich <rich@example.invalid> wrote:

Computer Nerd Kev <not@telling.you.invalid> wrote:

Computer Nerd Kev <not@telling.you.invalid> wrote:

I've got long strings like this from URLs (percent-encoded
characters have been decoded):

SdADygkIiM8ED8ZK/ZfkxwbHEgOXnsgKzQcYtq2j3L1HN6OYvET8PwvO2gpCCv4Bp4vIGLwLFN3dDQABOjWT0gVI/EtBlNUIObwLFNnU90IK/gCs2QQzBzhEz8sNAAdBPpmM+T0KRgudx88HxzsFnpjGQs8PBp+fEAvQCgCZnsdKzQz+lpbIBPj7CQ==

I believe they might be encrypted strings containing one or more
known fields, probably including a known ten digit number
(1409518286 in that case). They might also be hashes, but I think
it's unlikely.

I got a copy of the PHP code. Turns out it's a "transposition
cipher" which adds different numbers to the ASCII value of each
character in sequence.

Also called the Ceasar cipher:

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

Almost, but unlike the description there, the number of shifted
positions varies for each character in the encrypted string, since
the shift length depends on the ASCII value of each character in the
password. That means you couldn't simply shift the whole string all
the possible lengths until the string "1409518286" was found in the
result. Instead you'd have all the possible combinations of
independently shifted characters = 128 (ASCII character set) to the
power of the number of characters in the string. In this case
128^182 = 3.25e+383, which is ridiculous, but some shortcuts would

^^^^^^^
First thing I need to do is learn how to count characters in a
string (well actually I did, but forgot them number before I typed
it). Should've been:

128^188 = 1.43e+396

But it's base64 encoded, so if you don't know that, then multiply
that number by the number of different possible byte/character
encodings you'd have to try as well. If there isn't a smarter
approach.

Any cryptographer worthy of that label *should* recognize base64 on
sight. Really, any half decent programmer, esp. any half decent
programmer on Linux/Unix systems, should recognize base64 and uuencode
output immediately on sight, given how commonly both were used on Unix systems.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

not@telling.you.invalid (Computer Nerd Kev) writes:

Rich <rich@example.invalid> wrote:

Computer Nerd Kev <not@telling.you.invalid> wrote:

I got a copy of the PHP code. Turns out it's a "transposition
cipher" which adds different numbers to the ASCII value of each
character in sequence.

Also called the Ceasar cipher:

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

Almost, but unlike the description there, the number of shifted
positions varies for each character in the encrypted string, since the
shift length depends on the ASCII value of each character in the
password.

Sounds like the VigenŠre cipher, see https://en.wikipedia.org/wiki/Vigen%C3%A8re_cipher#Cryptanalysis for the
basics of how to break it.

That it was also base64 encoded would've thrown a spanner in the
works,

??? it should be a non-issue, you only have to base64-decode it once.

--
https://www.greenend.org.uk/rjk/

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Rich <rich@example.invalid> wrote:

Computer Nerd Kev <not@telling.you.invalid> wrote:

But it's base64 encoded, so if you don't know that, then multiply
that number by the number of different possible byte/character
encodings you'd have to try as well. If there isn't a smarter
approach.

Any cryptographer worthy of that label *should* recognize base64 on
sight. Really, any half decent programmer, esp. any half decent
programmer on Linux/Unix systems, should recognize base64 and uuencode output immediately on sight, given how commonly both were used on Unix systems.

Well I've seen plenty of base64 encoded data, I take it I should
have noticed some clue that distinguishes it from other strings of apparantly-random ASCII characters? Certainly it occurred to me to
try to base64 decode that string, which just got me the encrypted
bytes, and so no indication whether it was something base64 encoded
after encryption or not, since the result wasn't any more
intelligible. Since base64 doesn't have a fixed start/end string I
don't know what it is you imply hints that the string _must_ have
been base64 encoded when it doesn't decode to known-good output.

My whole point has been to find software that will try to crack the
encryption whether or not it has been encoded afterwards, as
base64, or another scheme. Playing the guessing game myself might
be of relative amusement to me if I'm ever stuck in prison cell for
life, but otherwise it's not something I want to waste much time
on. I wanted something that tries to crack the string with/without
base64 encoding, and then with any of the other many possible
encodings in decreasing order of likelihood:

https://en.wikipedia.org/wiki/Category:Binary-to-text_encoding_formats

--
__ __
#_ < |\| |< _#

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)