Decrypting usenet headers

[pragmatic]

This looks like symmetric encryption to me as first suggested, sleep walker. This certainly appears to be the default openssl format, where the first 8 bytes after the "Salted__" piece will be the salt, and the remaining (8) bytes are the encrypted data.

This does tell you a few things:

• This is most likely a block cipher, and moreover one that uses 8 byte blocks. DES or 3DES would be the most obvious candidates.
  
• The presence of this "Salted__" piece means that this was generated using a "passphrase" argument, rather than supplying a raw key.
  
• The underlying plaintext is 7 or fewer bytes. If it were 8 or longer there would be another ciphertext block (assuming standard/openssl default padding rules). This seems short for a unique account identifier but maybe they don't have that many, or maybe the "plaintext" is actually a packed int or long or something in which case it would be plenty. If it's truly an "account name" as you suggest, it's a short one.
  

What is doesn't tell you is what exact algorithm was being used, or what block mode was being used. My first guess would be CBC just because it's probably the most common, but there's no way to distinguish that here.

Your theoretical attack path looks like this:

• Attack the passphrase. This means you need to understand the key-derivation algorithm OpenSSL uses (which is here apparently) and then use the resulting key material (and IV material when testing non-ECB modes) to attempt to decrypt the ciphertext. If the output padding is correct, looks reasonable in terms of an identifier, and the passphrase looks like something a person would type then you've probably found the passphrase.
  
• Attack the key itself. Try every key and see if you get meaningful results. This will only work for DES and only in ECB mode. The upside is that it has a finite run time so you will either find it or you won't in a somewhat short order depending on your hardware, but truthfully this option isn't particularly realistic as I'll discuss below.
  

Now, you'll notice that I said "theoretical" attack path, because you have some serious problems here:

• I don't know of any tool to do either of the above attacks in any reasonably performant way. You can fairly easily write a program to do this, but it's going to be dog slow. Neither hashcat (nor John) can do what you're looking for to my knowledge.
  
• Perhaps as part of why no standard tool chains exist to do this, you are going to get tons of false positives like this. The only real sanity check you have is that the padding is correct, which is a very weak check. Beyond that you might be able to assume something about the underlying plaintext structure but then again maybe not. If you're doing the passphrase attack, for any passprase which generated a "valid" output you could attempt to decrypt a different ciphertext with that same passphrase and see if it also generates a valid output with the same basic account info structure, but long story short, this is going to be messy. For the attack against the key directly you can't even do this, hence why it's not really a viable option.
  

As for the "individual.net stuff", that's even more opaque. Assuming that encoding is base64, the output is 37 randomish bytes with no obvious meaningful structure. Without more samples I got nothing.

TL;DR version of your original question: it's very doubtful you're going to be able to make this correlation, at least not without more information.

I did recover the posting-host, but you said that was irrelevant so i'm assuming that won't help you.