From Newsgroup: comp.misc

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?
--
__ __
#_ < |\| |< _#
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

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...
--
__ __
#_ < |\| |< _#
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

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.
--
__ __
#_ < |\| |< _#
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

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/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

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
--
__ __
#_ < |\| |< _#
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Rich <rich@example.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
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.

I take it they didn't attack it by automated means using free
published software though? Which is all I'm really after. Like I
said, I can imagine ways one could code one's own optimised
software routines to help crack it, and I'm sure there are better
ones than I can immediately think of. But I don't get much fun out
of that myself and am only really interested if someone's published
their existing work in an easy-to-use form. Like the various free
password hash cracking tools for Linux.

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.

I looked in sci.crypt before posting but wasn't sure whether asking
about available cracking software was on topic or not. It seems
this thread is drifting away from that now anyway. The academic
aspects of cryptography are of limited interest to me beyond their
immediate pracical use to perform a real-world task. But I guess
if people are posting such challenges there, it does suggest that
most sci.crypt regulars don't know of free software to break them,
or else there might not be much point.

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.

The techniques to crack it efficiently must be significantly more
complex than the obvious brute-force approach to craching the
Ceasar Cipher.

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.

I was never proposing to use this method to encrypt things myself,
especially before I even knew what it was! My (correct, according
to you) assumption was that it _would_ likely be weaker than modern
encryption schemes, and therefore theoretically crackable. My
question was whether software was available to test that theory by
using known techniques to try and crack it, given I knew part of
the correct decoded output.

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.

Well not so much in this case since the content was mainly numbers
and random alpha-numeric strings, no words except for a domain name
and directory in a URL (in fact a pretty silly thing to encrypt).
That makes a practical technique to cracking it harder than what I
can immediately guess, but I suspected there would be cracking
techniques in use that are far more sophisticated than I can
imagine. Techniques possibly already implemented in free software,
but it seems maybe not.
--
__ __
#_ < |\| |< _#
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Richard Kettlewell <invalid@invalid.invalid> wrote:

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 Vigenere cipher, see https://en.wikipedia.org/wiki/Vigen%C3%A8re_cipher#Cryptanalysis for the basics of how to break it.

Thanks for the definition. In this case I (correctly) assumed that
the encrypted content wasn't going to be suitable for a frequency
analysis attack because it wasn't language but identifying numbers
and strings used for a database lookup and webpage generation. It
seems most other methods might not be relevant either, but perhaps
"Key elimination" can be used in an approach to guess the key
length and then determine the key (I'm not sure if the fixed value
subtracted as well as the current key letter value defeats that). I
can't say I'm really following the description of "Key elimination"
there on my first attempt.

Not knowing the encryption method used before I got access to the
encryption code (which also contains the key/password), I was
interested in whether software for an automatic brute-force attack
against all such weak ciphers was available. If it had been using
something as simple as the Caesar Cipher, it'd certainly be
possible.

The point is I didn't want to spend hours figuring out ways every
known cipher can/can't be most efficiently brute-forced, and then
how long it would take with the processing power available to me to
try each in sequence. I hoped there might be an open-source project
where people who find that more fun than I do had already combined
known brute-force cracking techniques for diffent ciphers into a
simple-to-use program that tries them all in turn. Like John The
Ripper (and others) for password hash cracking. In fact I thought
given all the different open-source password hash cracker projects,
it would be extremely likely (yes I know maybe they're easier to
write since they just have to generate hashes, but still). I did
find "bruteforce-salted-openssl", but it's for brute-force cracking
real modern encryption methods, with sufficient hints, not quirky
ancient ones that OpenSSL never used (I presume).

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.

Assuming a brute-force approach, trying likely sub-sets of all
possible decryption keys (in this case the key turned out to be a
single English word with some letters replaced with numbers),
unless you know that it's base64 encoded as well as encrypted, you
have to try to brute-force both the encoded and the base64-decoded
string to see if either contains the known text inside it. Plus all
the other possible ways you could encrypt text (assuming it was
ASCII text, not binary numbers, which being generated by a PHP
script it probably was) and get ASCII output, including other
binary-to-ASCII encoding schemes or a function of the encryption
algorithm itself which limits the range of bytes that it outputs.

Anyway, thanks but short of receiving software suggestions, I might
bail out of this discussion now because discussing ways I guess
such software might work is pointless and taking too much of my
time. I've spent far too long today thinking about and writing these
replies, which is basically what I wanted to avoid in the first
place by finding software written by people who'd thought this
through already. My problem is solved this time, and whether it's
possible or not, such software seemingly doesn't exist to help me
next time.
--
__ __
#_ < |\| |< _#
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

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

Rich <rich@example.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
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.

I take it they didn't attack it by automated means using free
published software though? Which is all I'm really after. Like I
said, I can imagine ways one could code one's own optimised
software routines to help crack it, and I'm sure there are better
ones than I can immediately think of. But I don't get much fun out
of that myself and am only really interested if someone's published
their existing work in an easy-to-use form. Like the various free
password hash cracking tools for Linux.

No, not as in "download 'crypto breaker 7.4, now with more breakage'
and simply plug it in. They cryptoanalysed the postings. There was
some software used for things like computing statistics of the stream
and the like, but not an "all-in-one" drop in a random base 64 encoded
url, and it churns and churns and reports an answer.

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.

I looked in sci.crypt before posting but wasn't sure whether asking
about available cracking software was on topic or not. It seems
this thread is drifting away from that now anyway. The academic
aspects of cryptography are of limited interest to me beyond their
immediate pracical use to perform a real-world task. But I guess
if people are posting such challenges there, it does suggest that
most sci.crypt regulars don't know of free software to break them,
or else there might not be much point.

Besides the occasional new crank that drops by with what they believe
is the "next best thing" the traffic there has dropped to effectively
zero. So even if you had posted, there likely wouldn't have been any
replies.

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.

The techniques to crack it efficiently must be significantly more
complex than the obvious brute-force approach to craching the
Ceasar Cipher.

A lot of the technique is/was looking for patterns, then deducing and
testing hypotheses from those patterns as to what the algorithm was.
So most of the work was "human intelligence". The tools were just
assistants to that intelligence aspect.

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.

I was never proposing to use this method to encrypt things myself,
especially before I even knew what it was! My (correct, according
to you) assumption was that it _would_ likely be weaker than modern encryption schemes, and therefore theoretically crackable. My
question was whether software was available to test that theory by
using known techniques to try and crack it, given I knew part of
the correct decoded output.

Is there software somewhere that might crack it? Maybe. Will you
likely find it on github/gitlab/sourceforge, I rather doubt so. Most
likely, if such software exists, it is sitting on the disk of whichever cryptographer created it for whatever they were attacking at the time,
and it (the software) has not moved beyond that location.

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.

Well not so much in this case since the content was mainly numbers
and random alpha-numeric strings, no words except for a domain name
and directory in a URL (in fact a pretty silly thing to encrypt).
That makes a practical technique to cracking it harder than what I
can immediately guess, but I suspected there would be cracking
techniques in use that are far more sophisticated than I can
imagine. Techniques possibly already implemented in free software,
but it seems maybe not.

Often web-dev's that "encrypt" URL's like this are doing it either to
satisfy some checkbox on a requirements sheet from whomever's paying
their salary, or from a mistaken belief that hiding whatever is inside
that package from view gives them "extra security". They would have
been better off, if they wanted the innards to remain "hidden from
view" in keeping the innards on their server, and simply creating a
unique random id that referenced the stored innards. Then clients have nothing to "ecrypt" because the random unique id is merely a pointer
back to a row in a db table that web browsers don't get to see.

--- Synchronet 3.22a-Linux NewsLink 1.2