[Concept] Image-Based File Encryption
-
Just an idea I got hit with a few hours ago. Just posting for the sake of community feedback and suggestions on if this is worth implementing or just a waste of time. I've been thinking that people have used steganosis to store data in image files ( and other types of files ) for years, but what about using images files to generate encryption keys? I think it's an interesting concept that had a fair degree of merit to it. Take this as an example. **************** open an image file, read in a 16 byte block of data and create an md5 fingerprint of that data. Write that data to an array. once this is done, read in the next logical 16 byte block of data and then create another md5 fingerprint of that block of data, writing that data to the next element in the previously specified array. continue this process until there are no 16 byte blocks of data remaining in the file. once this step is completed, we need to rebuild the array to assemble the checksums into a more usable form. we do this by taking the elements and rebuilding them into a new array. for example, lets assume we have 8 elements in the array. e0, e1, e2, e3, e4, e5, e6, e7 we would reshuffle the array by taking an element from the right end of the array and inserting them in between elements from the left end. for example: e0, e7, e1, e6, e2, e5, e4, e3 we then collapse these elements into a single string which in this case would be 1024 bits (128bytes). essentially this acts as an pad-generation algo due to it's ability to create keys of concievably any length. We can then perform any method of encryption that allows keys of arbitrary length using this data to encrypt our message. recovering the key would be a matter of using the same method to interrogate the image to derive it's key information. opinions on this would be appreciated.
It's good to see kids turning their minds to wholesum activities such as programming, instead of wasting their lives in the hedonistic disciplines of Sex, Drugs, & Rock & Roll... or Sex with Drugs, or Sex with Rocks while Rolling in Drugs, or whatever new-fangled perversions you little monsters have thought up now... [Shog9 on Kid Programmers]
-
Just an idea I got hit with a few hours ago. Just posting for the sake of community feedback and suggestions on if this is worth implementing or just a waste of time. I've been thinking that people have used steganosis to store data in image files ( and other types of files ) for years, but what about using images files to generate encryption keys? I think it's an interesting concept that had a fair degree of merit to it. Take this as an example. **************** open an image file, read in a 16 byte block of data and create an md5 fingerprint of that data. Write that data to an array. once this is done, read in the next logical 16 byte block of data and then create another md5 fingerprint of that block of data, writing that data to the next element in the previously specified array. continue this process until there are no 16 byte blocks of data remaining in the file. once this step is completed, we need to rebuild the array to assemble the checksums into a more usable form. we do this by taking the elements and rebuilding them into a new array. for example, lets assume we have 8 elements in the array. e0, e1, e2, e3, e4, e5, e6, e7 we would reshuffle the array by taking an element from the right end of the array and inserting them in between elements from the left end. for example: e0, e7, e1, e6, e2, e5, e4, e3 we then collapse these elements into a single string which in this case would be 1024 bits (128bytes). essentially this acts as an pad-generation algo due to it's ability to create keys of concievably any length. We can then perform any method of encryption that allows keys of arbitrary length using this data to encrypt our message. recovering the key would be a matter of using the same method to interrogate the image to derive it's key information. opinions on this would be appreciated.
It's good to see kids turning their minds to wholesum activities such as programming, instead of wasting their lives in the hedonistic disciplines of Sex, Drugs, & Rock & Roll... or Sex with Drugs, or Sex with Rocks while Rolling in Drugs, or whatever new-fangled perversions you little monsters have thought up now... [Shog9 on Kid Programmers]
I suppose, as a method of exchanging keys it might have some value, if only because no-one would expect it to be done that way.
-
Just an idea I got hit with a few hours ago. Just posting for the sake of community feedback and suggestions on if this is worth implementing or just a waste of time. I've been thinking that people have used steganosis to store data in image files ( and other types of files ) for years, but what about using images files to generate encryption keys? I think it's an interesting concept that had a fair degree of merit to it. Take this as an example. **************** open an image file, read in a 16 byte block of data and create an md5 fingerprint of that data. Write that data to an array. once this is done, read in the next logical 16 byte block of data and then create another md5 fingerprint of that block of data, writing that data to the next element in the previously specified array. continue this process until there are no 16 byte blocks of data remaining in the file. once this step is completed, we need to rebuild the array to assemble the checksums into a more usable form. we do this by taking the elements and rebuilding them into a new array. for example, lets assume we have 8 elements in the array. e0, e1, e2, e3, e4, e5, e6, e7 we would reshuffle the array by taking an element from the right end of the array and inserting them in between elements from the left end. for example: e0, e7, e1, e6, e2, e5, e4, e3 we then collapse these elements into a single string which in this case would be 1024 bits (128bytes). essentially this acts as an pad-generation algo due to it's ability to create keys of concievably any length. We can then perform any method of encryption that allows keys of arbitrary length using this data to encrypt our message. recovering the key would be a matter of using the same method to interrogate the image to derive it's key information. opinions on this would be appreciated.
It's good to see kids turning their minds to wholesum activities such as programming, instead of wasting their lives in the hedonistic disciplines of Sex, Drugs, & Rock & Roll... or Sex with Drugs, or Sex with Rocks while Rolling in Drugs, or whatever new-fangled perversions you little monsters have thought up now... [Shog9 on Kid Programmers]
Ahh..so innocent ;) I remember many years ago getting really *in* to cryptography, coming up with all sorts of ideas, being cruelly crushed by the reality of just how hard it actually is and how big the brains are of the people that come up with the existing systems. So if I understand you correctly, the encryption method itself could be any in use today, the difference is only in the key and how it's chosen and implemented? I think that it relies on the obscurity of the method used to choose the keys otherwise it's much more prone to being being "cracked" than a system where a user supplies a key on demand by typing it in: In the best case scenario: let's say the message is intercepted in transmission, the message is just as safe as the encryption method used since the 3rd party doesn't know how the key was chosen it's irrelevant to them either way. Any key length beyond usual standards isn't going to be any easier to crack in practice than anything longer. The worst case scenario: let's say someone steals your computer and want's to decrypt a file on your hard drive. If they know or can determine that a graphic image file will provide the key, they certainly know your not going to draw it by hand each time and they know you probably won't put it on a floppy, so it's probably any one of the graphic files that can be found on your hard drive. So you've just made what is a near infinite variety of possible keyphrases a user could type in brought down to a few thousand possible graphic files on a hard drive. Let's say on the other hand that you are using this internally in a single program, something like a licensing system for an application with an embedded graphic image file resource being used as the key. Aside from all the usual methods of patching the executable to simply bypass the encryption and license check entirely, it's also possible to easily see that the key is being derived from the image, in which case, assuming you have the image it's much easier to decrypt than something not included with the program itself. (which is why public and private key cryptographic algorithms were invented for just this sort of situation) The only advantage I can think of and it's not outweighing anything really, sorry :), is that at least a user won't be able to use their kid's names as a password or an easily guessed dictionary word. You can always get more obscure, that's easy. I could make an ecryption program that would encrypt files using a key determined by looking up the price of
-
Just an idea I got hit with a few hours ago. Just posting for the sake of community feedback and suggestions on if this is worth implementing or just a waste of time. I've been thinking that people have used steganosis to store data in image files ( and other types of files ) for years, but what about using images files to generate encryption keys? I think it's an interesting concept that had a fair degree of merit to it. Take this as an example. **************** open an image file, read in a 16 byte block of data and create an md5 fingerprint of that data. Write that data to an array. once this is done, read in the next logical 16 byte block of data and then create another md5 fingerprint of that block of data, writing that data to the next element in the previously specified array. continue this process until there are no 16 byte blocks of data remaining in the file. once this step is completed, we need to rebuild the array to assemble the checksums into a more usable form. we do this by taking the elements and rebuilding them into a new array. for example, lets assume we have 8 elements in the array. e0, e1, e2, e3, e4, e5, e6, e7 we would reshuffle the array by taking an element from the right end of the array and inserting them in between elements from the left end. for example: e0, e7, e1, e6, e2, e5, e4, e3 we then collapse these elements into a single string which in this case would be 1024 bits (128bytes). essentially this acts as an pad-generation algo due to it's ability to create keys of concievably any length. We can then perform any method of encryption that allows keys of arbitrary length using this data to encrypt our message. recovering the key would be a matter of using the same method to interrogate the image to derive it's key information. opinions on this would be appreciated.
It's good to see kids turning their minds to wholesum activities such as programming, instead of wasting their lives in the hedonistic disciplines of Sex, Drugs, & Rock & Roll... or Sex with Drugs, or Sex with Rocks while Rolling in Drugs, or whatever new-fangled perversions you little monsters have thought up now... [Shog9 on Kid Programmers]
This has been used in the movie Johnny Mnemonic[^]. The idea was to use a set of three random images captured from a television as encryption keys.
Software Zen:
delete this; -
Ahh..so innocent ;) I remember many years ago getting really *in* to cryptography, coming up with all sorts of ideas, being cruelly crushed by the reality of just how hard it actually is and how big the brains are of the people that come up with the existing systems. So if I understand you correctly, the encryption method itself could be any in use today, the difference is only in the key and how it's chosen and implemented? I think that it relies on the obscurity of the method used to choose the keys otherwise it's much more prone to being being "cracked" than a system where a user supplies a key on demand by typing it in: In the best case scenario: let's say the message is intercepted in transmission, the message is just as safe as the encryption method used since the 3rd party doesn't know how the key was chosen it's irrelevant to them either way. Any key length beyond usual standards isn't going to be any easier to crack in practice than anything longer. The worst case scenario: let's say someone steals your computer and want's to decrypt a file on your hard drive. If they know or can determine that a graphic image file will provide the key, they certainly know your not going to draw it by hand each time and they know you probably won't put it on a floppy, so it's probably any one of the graphic files that can be found on your hard drive. So you've just made what is a near infinite variety of possible keyphrases a user could type in brought down to a few thousand possible graphic files on a hard drive. Let's say on the other hand that you are using this internally in a single program, something like a licensing system for an application with an embedded graphic image file resource being used as the key. Aside from all the usual methods of patching the executable to simply bypass the encryption and license check entirely, it's also possible to easily see that the key is being derived from the image, in which case, assuming you have the image it's much easier to decrypt than something not included with the program itself. (which is why public and private key cryptographic algorithms were invented for just this sort of situation) The only advantage I can think of and it's not outweighing anything really, sorry :), is that at least a user won't be able to use their kid's names as a password or an easily guessed dictionary word. You can always get more obscure, that's easy. I could make an ecryption program that would encrypt files using a key determined by looking up the price of
John Cardinal wrote: how big the brains are of the people that come up with the existing systems. Have you ever read Applied Cryptography by Bruce Schneier? Bruce gave me a copy many years ago at a trade show, but try as I might I can only comprehend about 1/3 of the content. Mind you, my IQ is considerably higher than room temperature, unless one happens to live in a sauna (no Celsius jokes, please), but this stuff remains a black art to me.:sigh: John Cardinal wrote: it's probably any one of the graphic files that can be found on your hard drive. Perhaps the suggested method would be more secure if it relied on images from another source, a relatively static pr0n site, for instance.;) "If it's Snowbird season, why can't we shoot them?" - Overheard in a bar in Bullhead City
-
I suppose, as a method of exchanging keys it might have some value, if only because no-one would expect it to be done that way.
right. i mean, your average joe internet user isn't going to think "hey, that image has a encryption key in it." the average internet user doesn't even know what an encryption key is.
It's good to see kids turning their minds to wholesum activities such as programming, instead of wasting their lives in the hedonistic disciplines of Sex, Drugs, & Rock & Roll... or Sex with Drugs, or Sex with Rocks while Rolling in Drugs, or whatever new-fangled perversions you little monsters have thought up now... [Shog9 on Kid Programmers]
-
Ahh..so innocent ;) I remember many years ago getting really *in* to cryptography, coming up with all sorts of ideas, being cruelly crushed by the reality of just how hard it actually is and how big the brains are of the people that come up with the existing systems. So if I understand you correctly, the encryption method itself could be any in use today, the difference is only in the key and how it's chosen and implemented? I think that it relies on the obscurity of the method used to choose the keys otherwise it's much more prone to being being "cracked" than a system where a user supplies a key on demand by typing it in: In the best case scenario: let's say the message is intercepted in transmission, the message is just as safe as the encryption method used since the 3rd party doesn't know how the key was chosen it's irrelevant to them either way. Any key length beyond usual standards isn't going to be any easier to crack in practice than anything longer. The worst case scenario: let's say someone steals your computer and want's to decrypt a file on your hard drive. If they know or can determine that a graphic image file will provide the key, they certainly know your not going to draw it by hand each time and they know you probably won't put it on a floppy, so it's probably any one of the graphic files that can be found on your hard drive. So you've just made what is a near infinite variety of possible keyphrases a user could type in brought down to a few thousand possible graphic files on a hard drive. Let's say on the other hand that you are using this internally in a single program, something like a licensing system for an application with an embedded graphic image file resource being used as the key. Aside from all the usual methods of patching the executable to simply bypass the encryption and license check entirely, it's also possible to easily see that the key is being derived from the image, in which case, assuming you have the image it's much easier to decrypt than something not included with the program itself. (which is why public and private key cryptographic algorithms were invented for just this sort of situation) The only advantage I can think of and it's not outweighing anything really, sorry :), is that at least a user won't be able to use their kid's names as a password or an easily guessed dictionary word. You can always get more obscure, that's easy. I could make an ecryption program that would encrypt files using a key determined by looking up the price of
John, I appreciate the candor of your reply. While I think the method has merit, if it's implementation can be refined to an extreme degree, I can understand and also see the same security concerns in it's "psuedo-implementation" which I've outlined in my original post. The weakness -is- in the availability of the image file and the chance that it could, and probably would exist on the users hard-drive. in the event that it ultimately proves infeasible as a full blown encrpyption system, this could always become one component in a one-time-pad generation algo. least like to have -some- use out of it. Byzantine. I like that word. :-D
It's good to see kids turning their minds to wholesum activities such as programming, instead of wasting their lives in the hedonistic disciplines of Sex, Drugs, & Rock & Roll... or Sex with Drugs, or Sex with Rocks while Rolling in Drugs, or whatever new-fangled perversions you little monsters have thought up now... [Shog9 on Kid Programmers]
-
This has been used in the movie Johnny Mnemonic[^]. The idea was to use a set of three random images captured from a television as encryption keys.
Software Zen:
delete this;that could be kind of cool. sample random data from each quadrent of the image, using that data to build a new image which could then have md5 run over it's blocks of data and build a key from that, then resample the same images for more data, and use that to "morph" the original key. :-D Can anyone tell I'm stuck on this image thing?
It's good to see kids turning their minds to wholesum activities such as programming, instead of wasting their lives in the hedonistic disciplines of Sex, Drugs, & Rock & Roll... or Sex with Drugs, or Sex with Rocks while Rolling in Drugs, or whatever new-fangled perversions you little monsters have thought up now... [Shog9 on Kid Programmers]
-
John, I appreciate the candor of your reply. While I think the method has merit, if it's implementation can be refined to an extreme degree, I can understand and also see the same security concerns in it's "psuedo-implementation" which I've outlined in my original post. The weakness -is- in the availability of the image file and the chance that it could, and probably would exist on the users hard-drive. in the event that it ultimately proves infeasible as a full blown encrpyption system, this could always become one component in a one-time-pad generation algo. least like to have -some- use out of it. Byzantine. I like that word. :-D
It's good to see kids turning their minds to wholesum activities such as programming, instead of wasting their lives in the hedonistic disciplines of Sex, Drugs, & Rock & Roll... or Sex with Drugs, or Sex with Rocks while Rolling in Drugs, or whatever new-fangled perversions you little monsters have thought up now... [Shog9 on Kid Programmers]
John Aldrich wrote: in a one-time-pad generation algo That, on the other hand is a completely different story. In that case it becomes a pretty good system for encryption, just as good as the traditional one time pad which to my understanding is unbreakable by it's very nature, but still subject to the same exploits of knowing or procuring a copy of the image etc. What might be interesting is a more "fuzzy" algorithm that would allow (for example) a key to be determined from an image taken from a particular spot of a particular scene. Fuzzy in that two different people with different equipment could take the same picture and basically just be pointed in the right direction and in focus and the same key can be derived. Good enough for a spy novel idea at the very least. ;) Don't get me wrong, it's certainly possible for a novel new method of encryption to come along, it's just very despairing to believe that the more you read up on the subject. Of course history is filled with people who invented things mostly for the sole reason that someone told them it couldn't be done! In fact I think the saying should really be: "Skepticism is the mother of invention"