Use any digital photos to store text information 100% securely [Archive]

ckaihatsu

16th September 2012, 05:41

Can you post a higher resolution and bump up the jpeg quality? I'm on a 1080p monitor and the text is barely legible; artifacts from the jpeg compression don't help.

Yeah, I hear ya.

Each of the ten panels is 800x600, so it should be sufficient at actual size -- this issue just came up the other day on another thread:

I'm thinking / hoping that it may be due to the image being automatically resized down to fit in your screen....

After you click on the thumbnail to get the image in that stylized frame-window, click it again to see the image plainly on a blank browser page. Then click it *once more* and the browser will un-resize it to display it at its actual, original size -- it will probably not all fit in the browser window at once, then, so you may want to do a right-click on it and save it out to your local file directory. You can then use an image viewer of your choice to freely zoom in and out on it, and to pan around to see particular portions of it as you like.

For anyone viewing this thread: this method of data obfuscation is called steganography and is a fucking sneaky way of hiding things in plain sight.

Technically, it's *past* steganography, so to speak, since there's no algorithm being used that could conceivably be reversed, to get at the hidden image.

I was actually looking to implement something like the XOR operation, but for images -- the predecessor is attached, below.

Also, it's *almost* possible to do the same, but more easily, by setting up an image processing pipeline in NeoTextureEdit using nodes -- I haven't played with it too much, though.

NeoTextureEdit

http://neotextureedit.sourceforge.net/

XOR protocol

http://postimage.org/image/7qfa9yoh9/

Lynx

16th September 2012, 12:53

You listed a set of procedures that are reversible, how can it be secure?

ckaihatsu

16th September 2012, 13:37

You listed a set of procedures that are reversible, how can it be secure?

Yes -- it means that the mechanical / mathematical *process* is secure, like saying "This car drives well."

How people *use* it in real-world situations is beyond the design / engineering of the process itself.

The XOR or text-as-noise procedure is *not* reversible in the sense of it being open to being picked apart like an engine to see how it works, with a mind to retracing its steps and discovering its secrets.

Rather, it depends entirely on possession of an extremely specific "map", the original image that perfectly displaces the complementary image except for the very faint pixels that comprise the hidden text. It's more akin to a top-down photo of a room's floor that contains tiny particles of gold dust -- you would really need them circled in the photo to have any chance of recovering them.

ckaihatsu

28th December 2012, 13:55

I've since built on this technique, and developed a group communications protocol around it:

Affinity Group Image-Based Communications Protocol

http://postimage.org/image/ixpez2rql/

Sea

29th December 2012, 01:32

ckaihatsu

29th December 2012, 02:16

This could be useful for hiding encryption but it's not encryption in itself.

Still useful though, because when you start posting things like "Dr. Smith, on the ceiling, with a pipe." it obviously ain't plaintext. :laugh:

Yeah, and you may be indicating the factor of plausible deniability here, in the sense of wanting to show *zero* cause for suspicion in the first place.

The principle / spirit of steganography is to slip messages around unobtrusively, which -- as far as I can see -- is even more desirable than cryptography alone, as you're pointing out as well.

I'm surprised there isn't more use of the XOR operation for these kinds of things -- I didn't see much looking around the landscape when I was making preparations for one of my diagrams.

Here's an interesting read:

Chaffing and Winnowing: Confidentiality without Encryption

Ronald L. Rivest
MIT Lab for Computer Science
March 18, 1998 (rev. April 24, 1998)
http://theory.lcs.mit.edu/~rivest/chaffing.txt

A major goal of security techniques is ``confidentiality''---ensuring that
adversaries gain no intelligence from a transmitted message. There are
two major techniques for achieving confidentiality:

-- Steganography: the art of hiding a secret message within a
larger one in such a way that the adversary can not
discern the presence or contents of the hidden message.
For example, a message might be hidden within a picture
by changing the low-order pixel bits to be the message bits.
(See Wayner (1996) for more information on steganography.)

-- Encryption: transforming the message to a ciphertext such that
an adversary who overhears the ciphertext can not determine
the message sent. The legitimate receiver possesses a secret
decryption key that allows him to reverse the encryption
transformation and retrieve the message. The sender may have
used the same key to encrypt the message (with symmetric
encryption schemes) or used a different, but related key
(with public-key schemes). DES and RSA are familiar
examples of encryption schemes.

This paper introduces a new technique, which we call ``chaffing and
winnowing''---to winnow is to ``separate out or eliminate (the poor
or useless parts),'' (Webster's Dictionary), and is often used when
referring to the process of separating grain from chaff.

http://people.csail.mit.edu/rivest/Chaffing.txt

Sea

29th December 2012, 02:19

Yeah, and you may be indicating the factor of plausible deniability here, in the sense of wanting to show *zero* cause for suspicion in the first place.

The principle / spirit of steganography is to slip messages around unobtrusively, which -- as far as I can see -- is even more desirable than cryptography alone, as you're pointing out as well.

I'm surprised there isn't more use of the XOR operation for these kinds of things -- I didn't see much looking around the landscape when I was making preparations for one of my diagrams.

Here's an interesting read:
Try reloading the page.. I'm not sure what happened there.

ckaihatsu

29th December 2012, 03:54

edit: looks like it crapped out the center of my post

This could be useful for hiding encryption but it's not secure in itself. For instance, if you processed the image to only show groups of pixels that differ from there surrounding by a certain same value, you'd end up with a bunch of static and the message.

What you're assuming is that the values of the affected pixels would be changed according to an algorithmic definition. The definition you're giving, 'to only show groups of pixels that differ from their surrounding by a certain same value', *sounds* like a reasonable process to use, but in practice it's *meaningless* here.

The pixels of the plaintext message are layered on top. If the plaintext layer of pixels uses letterforms made up of random RGB noise then each pixel on this plaintext layer would have no algorithmic relation to any other, since they are all random. Adding such random values, even at a constant (1% visibility) application, would not disclose any overall pattern to their locations since [1] there is obviously no *visual* identification possible, [2] there is no pixel-lateral algorithmic pattern to be "cracked", and [3] there is no telltale *statistical* correlation from layer to layer.

The layout of pixel color values in the underlying 'cover' image give no clue as to whether any given pixel is an affected one or not. If one is, it could either be altered only slightly, perhaps by a similarly-colored overlay pixel, or it might be altered to a much greater degree, as by a *dissimilar* overlay pixel -- but it would still not be visible, and any 'range' you specify would just be an arbitrary portion out of the full color range, and would not be able to identify arbitrarily affected pixels using any focused, algorithmic approach.

In other words, the overlaying plaintext layer is arbitrary in composition and is randomized pixel-to-pixel. It is added on top of another arbitrary composition (a random photo) at 1% visibility. This mixture of random arbitrariness (the plaintext pixels of noise), added to a second arbitrariness (the cover image), does *not* disclose anything about either layer, or from one to the other.

Nothing can precisely specify which particular pixels to pick, and to precisely what (arbitrary random) values they should be imperceptibly shifted, to reveal the hidden faint pixels, except for the complementary image itself.

You may want to provide some examples.

Lynx

29th December 2012, 19:55

The specific unlocking image is a key.

ckaihatsu

29th December 2012, 20:26

The specific unlocking image is a key.

Yes, but only in the most 'pure', abstract definition, curiously -- there is no 'pins' mechanism to *this* lock -- it cannot be conventionally picked apart, understood, fooled, and circumvented. In this way the key-and-lock metaphor is more suited to simple exchange encryption algorithms since they *do* have a (mathematical) 'back-end' to their functioning.

This 'hiding' method makes use of a quite unique material property, and that's why it's difficult to even get a good grasp of it and its facets. In practice it might be likened to a 'trail of crumbs', where either you have the crumbs that indicate the message, or you don't -- in this case, the 'crumbs' being possession of the complementary image that reveals the hidden layer of very faint pixels.

Only the perfectly one-to-one per-pixel displacement by the original version of the image will "unhide" the invisibly faint pixels to reveal their own, secondary image.

This is a 'key' in the sense that a treasure map is a key to a very specific desired location.

Lynx

30th December 2012, 00:40

ckaihatsu

30th December 2012, 01:59

This key is a digital image, made up of numbers, just like any key used in software. A key is any piece of information necessary for recovery of a message. SHA-1 signatures can be used as keys, for example.

The strength of a key depends on its length and level of entropy. If the entire image is needed to reveal the text, then that is good. If it's only matching pixels that are needed, the required key length (the needed information) is shorter.

For the sake of clarification, each image component in a total transmission packet image, using this 'hiding' method, would have to match up to its complement -- there could be no variation in size *within* one packet image and its component layers and associated images.

You're erroneously conflating conventional encryption keys with this image-based 'hiding' type of key that I've outlined -- but it's *not* encryption, technically. The strength of this, or any one-time-pad (OTP) method, is that each %^$#@! individual elemental data block -- a byte or a pixel -- has *its own* arbitrary, random "encryption code", or authentication code, depending on how you look at it -- and that's its counterpart on the random-noise-based layer, or 'one-time pad'. Like the images, the blocks of text would be fixed-size, with the same character count for the corresponding random-garbage overlay, thereby producing a third string of characters that would look like garbage, like the second-layer overlay used. This would then be safe for transmission.

Your conventional approach of looking to inherent entropy in the cover image means that you're again mixing up conventional encryption dynamics / concerns with those of steganography, an entirely different approach to the task.

Also, much could be accomplished, as noted in the article, by simply doing an innocuous non-encryption data 'packaging' operation on the source folder, effectively constructing an all-or-nothing requirement for recovery of the volume from its pieces. This packaging, combined with the use of steganography -- or hiding -- would provide certainty on par with what you've described.

Using a single image file as a key is not a safe way to hide it. For the short term, it may be okay.

I'd be glad to hear any arguments or reasoning here.

An analysis of the numbers that represent a typical ckhaitsu key

I'm going to have 'ckaihatsu' added to all future versions of all spellcheckers....

would reveal its entropy, which is used to measure its unpredictability. Images contain patterns, and redundancies, much more so than information that has been compressed. The best keys are those that are pseudo-random, and have maximum entropy.

For example, "5" and "dddddddddd" have zero entropy. They are easily predictable, from a cryptographic perspective. It must take advanced techniques to defeat 128 bit keys, but it has been done.

There are people with Phd's in mathematics working on algorithms that are a lot more sophisticated than XOR operations. They argue amongst themselves as to which ones can be considered 'secure'.

What you're not realizing, either theoretically or from the 'hiding' method process, is that the XOR operation creates 'perfect' separations, or combinations, of arbitrary data components. This image-based method mimics that approach, but doesn't use the XOR mathematical operation exactly.

Again, this is distinct from the standard encryption approach.

Your method may be safe against casual snoopers, but why limit yourself? Steganographic software allows you to encrypt your message before hiding it, you may as well use the feature.

I have long been interested in these topics, if you have discovered an unbreakable process, you're guaranteed a Nobel prize.

And here I thought that email was just spam....

x D

Lynx

30th December 2012, 04:14

For the sake of clarification, each image component in a total transmission packet image, using this 'hiding' method, would have to match up to its complement -- there could be no variation in size *within* one packet image and its component layers and associated images.

You're erroneously conflating conventional encryption keys with this image-based 'hiding' type of key that I've outlined -- but it's *not* encryption, technically.
You are using a piece of information to recover hidden information - this process is generally referred to as decryption. Steganography is a technique for obfuscating (or 'encrypting') information within an image or other media file. A steganographic key has a property common to all keys - information.

The strength of this, or any one-time-pad (OTP) method, is that each %^$#@! individual elemental data block -- a byte or a pixel -- has *its own* arbitrary, random "encryption code", or authentication code, depending on how you look at it -- and that's its counterpart on the random-noise-based layer, or 'one-time pad'. Like the images, the blocks of text would be fixed-size, with the same character count for the corresponding random-garbage overlay, thereby producing a third string of characters that would look like garbage, like the second-layer overlay used. This would then be safe for transmission.
In other words, the key length is > = to the number of pixels needed to display the image. All OTPs are theoretically impossible to crack provided they are randomly generated.

Your conventional approach of looking to inherent entropy in the cover image means that you're again mixing up conventional encryption dynamics / concerns with those of steganography, an entirely different approach to the task.
Cryptanalysis techniques involve the use of entropy in one form or another. At minimum, it is used conceptually. The approach you are describing is not mechanical or optical - GIMP is a software program and manipulates images using computational models. Thus, the task for cryptanalysis would be to adopt the same approach. If there are optical techniques not yet emulated by software, then those could be useful too.

Also, much could be accomplished, as noted in the article, by simply doing an innocuous non-encryption data 'packaging' operation on the source folder, effectively constructing an all-or-nothing requirement for recovery of the volume from its pieces. This packaging, combined with the use of steganography -- or hiding -- would provide certainty on par with what you've described.
In other words, volume encryption?

I'd be glad to hear any arguments or reasoning here.
An image file as key is not inconspicuous, even if you have thousands of images. If your algorithm is known or suspected, and your computer is seized, investigators will run through all of your images as a first resort. It's the equivalent of having a key equal to a dictionary word.

I'm going to have 'ckaihatsu' added to all future versions of all spellcheckers....
Hey, I tried to get it right. I shall add it to my Firefox dictionary.

What you're not realizing, either theoretically or from the 'hiding' method process, is that the XOR operation creates 'perfect' separations, or combinations, of arbitrary data components. This image-based method mimics that approach, but doesn't use the XOR mathematical operation exactly.

Again, this is distinct from the standard encryption approach.
Distinct, yes, but not outside the realm of cryptanalysis or information theory.
The strength of your key will be based on its length and degree of entropy. If this process only generates pseudo-random keys, then they are not considered secure. Of more interest are non-deterministic processes. (The way GIMP used to crash did seem random...)

And here I thought that email was just spam....

x D
They will track you down. Such an achievement cannot be awarded posthumously.

ckaihatsu

30th December 2012, 09:24

You are using a piece of information to recover hidden information - this process is generally referred to as decryption. Steganography is a technique for obfuscating (or 'encrypting') information within an image or other media file. A steganographic key has a property common to all keys - information.

I'll maintain that there's a *technical* distinction between encryption and steganography since stego techniques don't actually *change* the data itself the way encryption does.

In other words, the key length is > = to the number of pixels needed to display the image. All OTPs are theoretically impossible to crack provided they are randomly generated.

Yes.

Cryptanalysis techniques involve the use of entropy in one form or another. At minimum, it is used conceptually. The approach you are describing is not mechanical or optical - GIMP is a software program and manipulates images using computational models. Thus, the task for cryptanalysis would be to adopt the same approach. If there are optical techniques not yet emulated by software, then those could be useful too.

Again you're smearing definitions together -- encryption is distinct from steganography in its approach and mechanics, and *both* are different from this 'hiding' approach that I've outlined.

In other words, volume encryption?

An image file as key is not inconspicuous, even if you have thousands of images. If your algorithm is known or suspected, and your computer is seized, investigators will run through all of your images as a first resort. It's the equivalent of having a key equal to a dictionary word.

There's *no algorithm*.

Given whatever circumstances, either having assorted images around will be considered 'normal' and not suspicious, or else it may be considered suspect, in which case an image-based protocol like this would *not* be a good method to use.

Hey, I tried to get it right. I shall add it to my Firefox dictionary.

Distinct, yes, but not outside the realm of cryptanalysis or information theory.

No algorithm = no possible mathematical solution for cryptanalysis to uncover.

The strength of your key will be based on its length and degree of entropy. If this process only generates pseudo-random keys, then they are not considered secure. Of more interest are non-deterministic processes. (The way GIMP used to crash did seem random...)

They will track you down. Such an achievement cannot be awarded posthumously.

A relief, truly.

= D

Lynx

30th December 2012, 16:57

I'll maintain that there's a *technical* distinction between encryption and steganography since stego techniques don't actually *change* the data itself the way encryption does.
Well, the purpose for which data is being changed is related to the technique. If you are using jpeg compression, are you using a steganographic technique? Lossy compression gets rid of redundant data that the eye won't notice. Your goal isn't to obfuscate visual information, rather to seek a balance between image quality and storage space.
Depending on your goal (decryption being one example), the level of entropy in each type of file is of importance. Compression tends to increase entropy, yet that doesn't make compression algorithms cryptographically secure. Typically, the data will end up in a form that is invulnerable to certain lines of attack, but vulnerable to others.

Yes.
Great. You should emphasize this. An OTP is a secure alternative to smaller size keys associated with 'traditional' encryption techniques.

Again you're smearing definitions together -- encryption is distinct from steganography in its approach and mechanics, and *both* are different from this 'hiding' approach that I've outlined.

There's *no algorithm*.
I don't see how there's no algorithm, even by a strict definition. You have provided a set of procedures, the only thing missing is a flowchart.
"Insert paper into shredder" is an example of an algorithm in the loosest sense. Recovering information from shredding requires an entirely different set of procedures and equipment.

Given whatever circumstances, either having assorted images around will be considered 'normal' and not suspicious, or else it may be considered suspect, in which case an image-based protocol like this would *not* be a good method to use.
If you're deleting hidden messages as soon as you're done with them, then it's not a problem. If you're paranoid, you can use volume encryption or the 'ultimate' option: encrypted partition with hidden volumes and decoy data.

If you're living in a country where "enhanced interrogation" techniques are in vogue, make your information as time sensitive as possible.

No algorithm = no possible mathematical solution for cryptanalysis to uncover.
This is incorrect. Obfuscated information can be retrieved without a known algorithm, and without a key. Whether your method is immune to all known cryptanalysis techniques is not for me to decide. Keep proclaiming it, though, the orthodoxy is always deliberately hard of hearing.

A relief, truly.

= D
If Nobel Prizes come in the form of a refreshing beverage, I'll second that.

ckaihatsu

31st December 2012, 01:41

Well, the purpose for which data is being changed is related to the technique. If you are using jpeg compression, are you using a steganographic technique?

No, of course not, since nothing is being concealed.

Lossy compression gets rid of redundant data that the eye won't notice. Your goal isn't to obfuscate visual information, rather to seek a balance between image quality and storage space.

Right.

Depending on your goal (decryption being one example), the level of entropy in each type of file is of importance. Compression tends to increase entropy, yet that doesn't make compression algorithms cryptographically secure. Typically, the data will end up in a form that is invulnerable to certain lines of attack, but vulnerable to others.

You're digressing, to a discussion about encryption.

Great. You should emphasize this. An OTP is a secure alternative to smaller size keys associated with 'traditional' encryption techniques.

Thanks -- my immediate aim was to just get it out there as a ready-to-use tool, but I'll keep this in mind for any future revisions or additions.

I don't see how there's no algorithm, even by a strict definition. You have provided a set of procedures, the only thing missing is a flowchart.
"Insert paper into shredder" is an example of an algorithm in the loosest sense.

Manual procedures on the part of the user is entirely different from an actual computer programmed algorithm. You're obviously stretching here in an attempt to 'save face' -- don't worry about it, but just please note this distinction of fact.

Again, this 'hiding' method uses no algorithm.

Recovering information from shredding requires an entirely different set of procedures and equipment.

If you're deleting hidden messages as soon as you're done with them, then it's not a problem. If you're paranoid, you can use volume encryption or the 'ultimate' option: encrypted partition with hidden volumes and decoy data.

If you're living in a country where "enhanced interrogation" techniques are in vogue, make your information as time sensitive as possible.

No algorithm = no possible mathematical solution for cryptanalysis to uncover.

This is incorrect. Obfuscated information can be retrieved without a known algorithm, and without a key.

Again, I'm open to examples for this.

Whether your method is immune to all known cryptanalysis techniques is not for me to decide. Keep proclaiming it, though, the orthodoxy is always deliberately hard of hearing.

Thanks. You may want to go ahead and do what you think is necessary to make a decision as to whether this method matches up to its / my claims. (Hint: Cryptanalysis doesn't work on it.)

If Nobel Prizes come in the form of a refreshing beverage, I'll second that.

Lynx

31st December 2012, 16:28

You're digressing, to a discussion about encryption.
What would you prefer, a discussion about image processing?
The task is to uncover hidden information using whatever tools and resources are available.

Manual procedures on the part of the user is entirely different from an actual computer programmed algorithm. You're obviously stretching here in an attempt to 'save face' -- don't worry about it, but just please note this distinction of fact.

Again, this 'hiding' method uses no algorithm.
Manual procedures are a feature of every obfuscation scheme. Yet you have omitted one procedure that is recommended: encryption of the message before hiding it.
The rest of your process uses an algorithm in the strict sense (GIMP tools) and the output consists of a key and an obfuscated message.

Again, I'm open to examples for this.
Code breaking during WW2, hacking of mobile phone encryption, finding collisions within hashing functions. Work continues to find vulnerabilities in the latest encryption schemes.

Thanks. You may want to go ahead and do what you think is necessary to make a decision as to whether this method matches up to its / my claims. (Hint: Cryptanalysis doesn't work on it.)
Cryptanalysis is applicable to your method. Any OTP is considered unbreakable if it is sufficiently random and that is the only variable left to be determined.

Suffice to say you shouldn't use an image that has copies/variations of it floating around the internet.

ckaihatsu

31st December 2012, 17:10

What would you prefer, a discussion about image processing?
The task is to uncover hidden information using whatever tools and resources are available.

Just sayin' -- feel free to expound....

Manual procedures are a feature of every obfuscation scheme. Yet you have omitted one procedure that is recommended: encryption of the message before hiding it.

Your advice here stems from a perspective of steganalysis (as distinct from cryptanalysis), where one could conceivably want to first have the data encrypted in case the steganographic measures were to be overcome.

You're not understanding that what I have developed and introduced is a *third* option or mode of discreet information transmission, one that is identical to one-time pads (OTP) in methodology.

The rest of your process uses an algorithm in the strict sense (GIMP tools) and the output consists of a key and an obfuscated message.

'GIMP tools' does *not* qualify as an algorithm. There is no function performed on the incoming data (image layers) that subjects it to any transformation of its content, as would be synonymous with the use of encryption.

The one-image output, from two discrete, same-size inputs, looks *identical* to the original 'cover' (OTP) image that is one of the two inputs (the other input being the plaintext message, in RGB noise letterforms for the text).

So the simple layering of the plaintext message layer at a 1% opacity on top of the cover image does *not* constitute an algorithm. It *does* require a mathematical operation, but that is simply for the image-processing of it, and is nowhere near *altering* the data algorithmically, or even *distributing* it steganographically (also algorithmic).

Code breaking during WW2, hacking of mobile phone encryption, finding collisions within hashing functions. Work continues to find vulnerabilities in the latest encryption schemes.

Get them to bet *against* the efficacy of this method.

Cryptanalysis is applicable to your method.

No, it isn't.

Any OTP is considered unbreakable if it is sufficiently random and that is the only variable left to be determined.

Yes, and my method *uses* an image-based analogue of OTP.

Suffice to say you shouldn't use an image that has copies/variations of it floating around the internet.

Yes.

Lynx

31st December 2012, 22:37

Just sayin' -- feel free to expound....
Expound on what? The utility of color models? Spectral analysis?

Your advice here stems from a perspective of steganalysis (as distinct from cryptanalysis), where one could conceivably want to first have the data encrypted in case the steganographic measures were to be overcome.

You're not understanding that what I have developed and introduced is a *third* option or mode of discreet information transmission, one that is identical to one-time pads (OTP) in methodology.
Very well, assuming that it meets the definition of a OTP, that step would not be required.

'GIMP tools' does *not* qualify as an algorithm. There is no function performed on the incoming data (image layers) that subjects it to any transformation of its content, as would be synonymous with the use of encryption.

The one-image output, from two discrete, same-size inputs, looks *identical* to the original 'cover' (OTP) image that is one of the two inputs (the other input being the plaintext message, in RGB noise letterforms for the text).

So the simple layering of the plaintext message layer at a 1% opacity on top of the cover image does *not* constitute an algorithm. It *does* require a mathematical operation, but that is simply for the image-processing of it, and is nowhere near *altering* the data algorithmically, or even *distributing* it steganographically (also algorithmic).
There is no formal definition for an algorithm. The term existed before the advent of computer science, and now applies to other concepts. It is almost as general a term as 'process' and 'product'.
Your output must have been transformed, its data altered, otherwise a key would not be needed.

Get them to bet *against* the efficacy of this method.
You find them, you submit it to them, and use your own money.

No, it isn't.
Yes, it is. Your product is created, stored and displayed electronically. It isn't comprised of invisible ink or shredded bits of paper. It doesn't contain materials that fluoresce under certain wavelengths of light.

Yes, and my method *uses* an image-based analogue of OTP.
Which is precisely why much of this discussion is moot, especially the 'algorithm' part. How you create a OTP is not important, only that it meets the definition of one.

ckaihatsu

1st January 2013, 03:28

Expound on what? The utility of color models? Spectral analysis?

Yup. All of it. Go nuts.

= )

Very well, assuming that it meets the definition of a OTP, that step would not be required.

There is no formal definition for an algorithm. The term existed before the advent of computer science, and now applies to other concepts. It is almost as general a term as 'process' and 'product'.

The amount of twisting you're doing here is just too much -- you're about to kick off a new dance craze with it....

= p

To clarify then, I mean the *formal* definition for 'algorithm' -- that it is a linear set of instructions carried out using mathematical operations.

Noun

algorithm (plural algorithms)

A precise step-by-step plan for a computational procedure that possibly begins with an input value and yields an output value in a finite number of steps. [quotations ▼]

(archaic) Calculation with Arabic numerals; algorism.

http://en.wiktionary.org/wiki/algorithm

Again, this 'hiding' method uses no algorithm.

Your output must have been transformed, its data altered, otherwise a key would not be needed.

No, I'm making a distinction between data *content* being altered -- encryption -- and what is essentially a signals-processing step, wherein the plaintext layer of random-color pixels for the text becomes very limited in its color-spectrum range. (And this is the "catch", or material trade-off here -- by going the signals-processing route, we step into *that* realm and will see a cost of hidden-layer image degradation due to its being treated like a lightwave for the purpose of concealing it.)

The key -- more like an XOR component -- simply neutralizes the precise, correct amount of 'cover' lightwave signal, thereby leaving behind the invisible pixels of the hidden component, to be recovered.

Yes, it is. Your product is created, stored and displayed electronically. It isn't comprised of invisible ink or shredded bits of paper. It doesn't contain materials that fluoresce under certain wavelengths of light.

Which is precisely why much of this discussion is moot, especially the 'algorithm' part. How you create a OTP is not important, only that it meets the definition of one.

I don't know why you're having difficulty with understanding this -- you know what a OTP is, so you *should* know that that doesn't use any algorithm. You're accepting that my 'hiding' method is *like* a OTP, so that should mean that you know it doesn't use an algorithm either.

You're making it sound like *everything electronic* is algorithmic, but that isn't so -- an algorithm is synonymous with a computer program, or 'application'.

Lynx

1st January 2013, 15:03

The amount of twisting you're doing here is just too much -- you're about to kick off a new dance craze with it....
Yup, The Algorithm, Gangnam style.

To clarify then, I mean the *formal* definition for 'algorithm' -- that it is a linear set of instructions carried out using mathematical operations.
That narrows it down to your XOR like mathematical operation.

No, I'm making a distinction between data *content* being altered -- encryption -- and what is essentially a signals-processing step, wherein the plaintext layer of random-color pixels for the text becomes very limited in its color-spectrum range. (And this is the "catch", or material trade-off here -- by going the signals-processing route, we step into *that* realm and will see a cost of hidden-layer image degradation due to its being treated like a lightwave for the purpose of concealing it.)

The key -- more like an XOR component -- simply neutralizes the precise, correct amount of 'cover' lightwave signal, thereby leaving behind the invisible pixels of the hidden component, to be recovered.
You'll have to explain where you are obtaining spectral information from a color model. You can obtain imagery that contains spectral information, such as LANDSAT-X, but this is not what you have described. Your image is in RGB.

We are entering the realm of mathematical modeling of real world phenomena, which may yield statistically useful results, but are not random.

I don't know why you're having difficulty with understanding this -- you know what a OTP is, so you *should* know that that doesn't use any algorithm. You're accepting that my 'hiding' method is *like* a OTP, so that should mean that you know it doesn't use an algorithm either.
An accepted method of generating a OTP is to use a hardware random number generator. This is a non-trivial operation that involves sampling of non-deterministic processes. These and older methods use algorithms. Don't get hung up on the use of the term, 'method', 'process', and 'procedure' are acceptable replacements.

You're making it sound like *everything electronic* is algorithmic, but that isn't so -- an algorithm is synonymous with a computer program, or 'application'.
Yes, the strict definition is synonymous with computing. (See this (https://en.wikipedia.org/wiki/Algorithm_characterizations) if you are interested in the brouhaha surrounding the term) By electronic, I'm referring to the way that data and information are handled and stored. A digital device such as a computer processes and stores data as binary numbers. Data is stored in a format that is accessible and can be analyzed.
A computer cannot reveal information written in invisible ink because that requires a chemical process. There may be other methods to reveal such information, such as measuring the reflectance of wavelengths, and using a computer to analyze the results, but those results (raw data) must first be generated.
These are your 'realms'.

Lynx

1st January 2013, 15:05

There must be a club or group who would be willing to put your method to the test. If they fail, they can pass it on to their colleagues.

ckaihatsu

1st January 2013, 16:32

That narrows it down to your XOR like mathematical operation.

Yeah, so I'll leave it at that. You obviously understand and I don't want to mince around in semantics.

You'll have to explain where you are obtaining spectral information from a color model. You can obtain imagery that contains spectral information, such as LANDSAT-X, but this is not what you have described. Your image is in RGB.

Huh? I was attempting to relate that a whole image is a "lightwave", with varying distributions (quantities) of all of the possible colors, depending on the given image.

This is in the realm of fields of radiation, whether electromagnetic (as with colored light), or sound, or otherwise.

We are entering the realm of mathematical modeling of real world phenomena, which may yield statistically useful results, but are not random.

An accepted method of generating a OTP is to use a hardware random number generator. This is a non-trivial operation that involves sampling of non-deterministic processes.

So you're going to call me on a *technicality*, because my method requires a prerequisite algorithmic operation to generate the random data -- ? -- !

What if the random data was derived from radioactive decay and was streamed to the net, like a world time-clock server -- ? Then it wouldn't involve an algorithm, even for the random-data part.

These and older methods use algorithms. Don't get hung up on the use of the term, 'method', 'process', and 'procedure' are acceptable replacements.

Yes, the strict definition is synonymous with computing. (See this (https://en.wikipedia.org/wiki/Algorithm_characterizations) if you are interested in the brouhaha surrounding the term) By electronic, I'm referring to the way that data and information are handled and stored. A digital device such as a computer processes and stores data as binary numbers. Data is stored in a format that is accessible and can be analyzed.
A computer cannot reveal information written in invisible ink because that requires a chemical process. There may be other methods to reveal such information, such as measuring the reflectance of wavelengths, and using a computer to analyze the results, but those results (raw data) must first be generated.
These are your 'realms'.

Lynx

2nd January 2013, 15:10

Huh? I was attempting to relate that a whole image is a "lightwave", with varying distributions (quantities) of all of the possible colors, depending on the given image.
Metaphorically it is. Technically, each color model offers a color space, with a subset of possible colors or gamut.

This is in the realm of fields of radiation, whether electromagnetic (as with colored light), or sound, or otherwise.
I thought you were referring to the behavior of these real world phenomena, and that you were using them as part of your method.

So you're going to call me on a *technicality*, because my method requires a prerequisite algorithmic operation to generate the random data -- ? -- !

What if the random data was derived from radioactive decay and was streamed to the net, like a world time-clock server -- ? Then it wouldn't involve an algorithm, even for the random-data part.
I believe this is what 'sampling' is referring to. It would be nice to have a convenient source of random data, but in any case these 'generators' work without any user input other than pushing a button and waiting for the output. Operationally, they have to go through a whole song and dance.

I don't understand why the absence of an 'algorithm' would make your method unbreakable.

p.s. Sorry for the slow pace of response, RL is rather hectic at the moment.

ckaihatsu

2nd January 2013, 18:25

Metaphorically it is. Technically, each color model offers a color space, with a subset of possible colors or gamut.

There are *two* different concepts being batted around here -- I know what gamut is, but hang onto the whole-image-as-a-lightwave concept for a moment....

This is in the realm of fields of radiation, whether electromagnetic (as with colored light), or sound, or otherwise.

I thought you were referring to the behavior of these real world phenomena, and that you were using them as part of your method.

Right -- that's the point: although the *medium* for these images is digital, we can operationally treat the arrays of pixels as one particular distribution of colors at varying intensities across the full color gamut, as is seen in the 'Levels' command.

I believe this is what 'sampling' is referring to. It would be nice to have a convenient source of random data, but in any case these 'generators' work without any user input other than pushing a button and waiting for the output. Operationally, they have to go through a whole song and dance.

Yeah, I don't know enough to go into depth....

I don't understand why the absence of an 'algorithm' would make your method unbreakable.

[CORRECTION IN BRACKETS] Well, think about it -- if a certain configuration of pure randomness for the pixels, [at an invisible opacity of only 1%, is what's altering the cover image, to where the alteration is *visually imperceptible*, then by what information would an adversary even possibly be working with -- ? One could even *tell* the adversary about this method, and that one will be using it, and it *still* wouldn't help the adversary at all.]

[T]here is *never* any algorithmic pattern that could ever be cracked with cryptanalysis or steganalysis. All possible mathematical-based attempts would be pointless, rendering those methods powerless. Again, think of the one-time pad.

In post #5 Sea claimed to have found a weakness inherent in the method, but didn't elaborate. At this point I'd certainly welcome any peer review, etc.

p.s. Sorry for the slow pace of response, RL is rather hectic at the moment.

Tell it to fuck off.

= )

ckaihatsu

2nd January 2013, 20:51

The fun concept here is that the material substance of the package to be transmitted is operationally 'halved', so that recovery is necessarily a 2-step all-or-nothing process.

(If an adversary gets the original *cover image* but doesn't have its complement, the OTI+MSG (one-time-image / cover image, plus message of letterforms of random-RGB-noise pixels for the text, overlaid at 1% opacity), then the adversary *physically* does not have the message whatsoever. If the adversary only gets the OTI+MSG image, there's no way to differentiate the affected pixels from the rest, nor would one know exactly the slight variations in values to use to define the *original* cover image, to displace the exact original image to reveal the overlaid hidden pixels.)

This is really in the spirit of XOR, so to speak -- developing to this current point has been an endeavor of sorts....

Lynx

4th January 2013, 18:11

There are *two* different concepts being batted around here -- I know what gamut is, but hang onto the whole-image-as-a-lightwave concept for a moment....

Right -- that's the point: although the *medium* for these images is digital, we can operationally treat the arrays of pixels as one particular distribution of colors at varying intensities across the full color gamut, as is seen in the 'Levels' command.

Yeah, I don't know enough to go into depth....
Ditto.

[CORRECTION IN BRACKETS] Well, think about it -- if a certain configuration of pure randomness for the pixels, [at an invisible opacity of only 1%, is what's altering the cover image, to where the alteration is *visually imperceptible*, then by what information would an adversary even possibly be working with -- ? One could even *tell* the adversary about this method, and that one will be using it, and it *still* wouldn't help the adversary at all.]
Obfuscated image + key = revealed image?
vs.
Obfuscated image XOR key = revealed image?

[T]here is *never* any algorithmic pattern that could ever be cracked with cryptanalysis or steganalysis. All possible mathematical-based attempts would be pointless, rendering those methods powerless. Again, think of the one-time pad.
There is no mathematical proof that a one time pad is impossible to break. And OTPs have been broken in the past due to insufficient randomness (ie.human error during implementation).

In post #5 Sea claimed to have found a weakness inherent in the method, but didn't elaborate. At this point I'd certainly welcome any peer review, etc.
Yes, practice trumps theory.

Tell it to fuck off.

= )
Nice theory.

ckaihatsu

5th January 2013, 02:43

Ditto.

Obfuscated image + key = revealed image?
vs.
Obfuscated image XOR key = revealed image?

Please note that *nothing* is 'obfuscated' -- the laden image used for transmission does not *look* affected, or obfuscated in any way. After all, that's the point -- it shouldn't be readily identifiable.

Here's a schematic for the XOR operation, illustrated:

http://s6.postimage.org/nhp1d4wz1/2012307530046342459_TAd_Kv_C_fs.jpg (http://postimage.org/image/nhp1d4wz1/)

- One-time-image (OTI) used to hide message (MSG):

[OTI] -HIDE- [MSG] = [OTI+MSG]

- Laden cover image used in XOR-like way with original OTI -- used here in a key-like way -- to where the original OTI's particular layout of color values over its grid of pixels "neutralizes" the exact same grid layout of numeric color values in the [OTI+MSG] image, leaving only the *difference* (in color values, per pixel) remaining: the hidden message layer pixels, to be recovered:

[OTI+MSG] -DIFFERENCE- [OTI] = MSG (invisible pixels, to be recovered)

Also, consider the very limited range of color values that would allow for the "hidden" effect, across all colors, when it came to compositing the two layers for the OTI+MSG image -- that would explain why the gamut (color space) for the hidden layer is severely limited / degraded, showing a crude, unwanted posterization effect.

There is no mathematical proof that a one time pad is impossible to break.

In cryptography, the one-time pad (OTP) is a type of encryption which has been proven to be impossible to crack if used correctly. Each bit or character from the plaintext is encrypted by a modular addition with a bit or character from a secret random key (or pad) of the same length as the plaintext, resulting in a ciphertext. If the key is truly random, as large as or greater than the plaintext, never reused in whole or part, and kept secret, the ciphertext will be impossible to decrypt or break without knowing the key.[1][2]

http://en.wikipedia.org/wiki/One-time_pad

And OTPs have been broken in the past due to insufficient randomness (ie.human error during implementation).

Yes, practice trumps theory.

Nice theory.