There are countless ways to do steganography, "hide in the least significant bits" is just one way. Unless you have more information what that program actually does, no one can tell you how to get rid of the hidden information with certainty - although JPEG compression will work most likely.

But what I actually find more worrying:

• Your point of view on cryptography is somewhat pessimistic: AES 128 and RSA 2048 surely aren't "weak" in the sense that they can be broken if you use enough computation power. And there isn't really a "game", like the arms race in other areas of IT security.
• But despite that, you trust some implementation without any documentation of which algorithm they actually use to hide your information, if they have done any kind of testing or quality assurance, and if there was any security analysis done.

Before you worry about using AES 256 instead of 128, it would be way more important to look into the kind of software you are using. Security breaks at its weakest link, and that's definately not AES 128.

And yes, I'm well aware of the overkill that is 256-bit symmetric encryption. I just don't like that the cryptography community has to wait until something is deemed insecure before we switch to more advanced techniques (like switching from 1024-bit RSA to 2048-bit RSA, meanwhile we could simply be using 4096-bit RSA and be much safer for more time to come with very little performance tradeoff

Actually, key length suggestions tend to be absolute worst case assumptions, and statements like "AES 128 is weak" are on a scale "using all computational power of the earth for millions of years". Going from RSA 2048 to RSA 4096 can surely be done, but that's an overkill on an even larger scale. And considering that "little performance tradeoff", this is true if you do just one RSA opration. But already the key generation takes quite a lot longer, and this statement can't be generalized to all kinds of algorithms and protocols.

I do think using AES 256 and RSA 4096 is really good. But not because of some unfounded worries about smaller keys. The reason could be: It's the upper limit of what is currently considered state-of-the-art (and commonly used).

There are countless ways to do steganography, "hide in the least significant bits" is just one way. Unless you have more information what that program actually does, no one can tell you how to get rid of the hidden information with certainty - although JPEG compression will work most likely.

If you want to actually find where the data was hidden, try to find some part, e.g. the few least significant bits, which look like white noise (uniform random bits). Today's encryption schemes require ciphertext to be indistinguishable from randomness, as long as you don't know the key. And then if you overwrite this with $0$s, $1s$ or other randomness, you will destroy the original information. Even if you just overwrite a small part of each block of ciphertext, the original message is impossible to reconstruct.

But what I actually find more worrying:

• Your point of view on cryptography is somewhat pessimistic: AES 128 and RSA 2048 surely aren't "weak" in the sense that they can be broken if you use enough computation power. And there isn't really a "game", like the arms race in other areas of IT security.
• But despite that, you trust some implementation without any documentation of which algorithm they actually use to hide your information, if they have done any kind of testing or quality assurance, and if there was any security analysis done.

Before you worry about using AES 256 instead of 128, it would be way more important to look into the kind of software you are using. Security breaks at its weakest link, and that's definately not AES 128.

And yes, I'm well aware of the overkill that is 256-bit symmetric encryption. I just don't like that the cryptography community has to wait until something is deemed insecure before we switch to more advanced techniques (like switching from 1024-bit RSA to 2048-bit RSA, meanwhile we could simply be using 4096-bit RSA and be much safer for more time to come with very little performance tradeoff

Actually, key length suggestions tend to be absolute worst case assumptions, and statements like "AES 128 is weak" are on a scale "using all computational power of the earth for millions of years". Going from RSA 2048 to RSA 4096 can surely be done, but that's an overkill on an even larger scale. And considering that "little performance tradeoff", this is true if you do just one RSA opration. But already the key generation takes quite a lot longer, and this statement can't be generalized to all kinds of algorithms and protocols.

I do think using AES 256 and RSA 4096 is really good. But not because of some unfounded worries about smaller keys. The reason could be: It's the upper limit of what is currently considered state-of-the-art (and commonly used).

There are countless ways to do steganography, "hide in the least significant bits" is just one way. Unless you have more information what that program actually does, no one can tell you how to get rid of the hidden information with certainty - although JPEG compression will work most likely.

But what I actually find more worrying:

• Your point of view on cryptography is somewhat pessimistic: AES 128 and RSA 2048 surely aren't "weak" in the sense that they can be broken if you use enough computation power. And there isn't really a "game", like the arms race in other areas of IT security.
• But despite that, you trust some implementation without any documentation of which algorithm they actually use to hide your information, if they have done any kind of testing or quality assurance, and if there was any security analysis done.

Before you worry about using AES 256 instead of 128, it would be way more important to look into the kind of software you are using. Security breaks at its weakest link, and that's definately not AES 128.

And yes, I'm well aware of the overkill that is 256-bit symmetric encryption. I just don't like that the cryptography community has to wait until something is deemed insecure before we switch to more advanced techniques (like switching from 1024-bit RSA to 2048-bit RSA, meanwhile we could simply be using 4096-bit RSA and be much safer for more time to come with very little performance tradeoff

Actually, key length suggestions tend to be absolute worst case assumptions, and statements like "AES 128 is weak" are on a scale "using all computational power of the earth for millions of years". Going from RSA 2048 to RSA 4096 can surely be done, but that's an overkill on an even larger scale. And considering that "little performance tradeoff", this is true if you do just one RSA opration. But already the key generation takes quite a lot longer, and this statement can't be generalized to all kinds of algorithms and protocols.

There are countless ways to do steganography, "hide in the least significant bits" is just one way. Unless you have more information what that program actually does, no one can tell you how to get rid of the hidden information with certainty - although JPEG compression will work most likely.

But what I actually find more worrying:

• Your point of view on cryptography is somewhat pessimistic: AES 128 and RSA 2048 surely aren't "weak" in the sense that they can be broken if you use enough computation power. And there isn't really a "game", like the arms race in other areas of IT security.
• But despite that, you trust some implementation without any documentation of which algorithm they actually use to hide your information, if they have done any kind of testing or quality assurance, and if there was any security analysis done.

Before you worry about using AES 256 instead of 128, it would be way more important to look into the kind of software you are using. Security breaks at its weakest link, and that's definately not AES 128.

And yes, I'm well aware of the overkill that is 256-bit symmetric encryption. I just don't like that the cryptography community has to wait until something is deemed insecure before we switch to more advanced techniques (like switching from 1024-bit RSA to 2048-bit RSA, meanwhile we could simply be using 4096-bit RSA and be much safer for more time to come with very little performance tradeoff

Actually, key length suggestions tend to be absolute worst case assumptions, and statements like "AES 128 is weak" are on a scale "using all computational power of the earth for millions of years". Going from RSA 2048 to RSA 4096 can surely be done, but that's an overkill on an even larger scale. And considering that "little performance tradeoff", this is true if you do just one RSA opration. But already the key generation takes quite a lot longer, and this statement can't be generalized to all kinds of algorithms and protocols.

I do think using AES 256 and RSA 4096 is really good. But not because of some unfounded worries about smaller keys. The reason could be: It's the upper limit of what is currently considered state-of-the-art (and commonly used).