1. OT: how to securely produce a large data file for "one time tape" encryption input

Hello,
I plan on writing some Euphoria to help thwart the keyloggers/voice recorders/data capturing thats quite prevalent in the dominant OS, and getting worse with the version just announced. In essence, I want to logically "and" my clear text with a large datafile which is stored deliberately on a full DVD. As long as the DVD data is not available, the OTT (one time tape) should be secure. The DVD is only mounted when needed, so there is no way its contents could be read (any significant part) without that being obvious.. spinning DVD, light on etc. Downside is the usual - the intended recipient needs a copy of the DVD, but thats OK, can be arranged. The euphoria program will note the start and end position of the DVD data. So, with that background, the question is how to produce said DVD without it being surreptitiously copied?
How about using a VM image with Truecrypt v7.1a loaded, no network to VM, transfer the file to off-PC, then scrap the VM; Burn the DVD using a more secure OS.
Any better ideas, comments..?

new topic     » topic index » view message » categorize

2. Re: OT: how to securely produce a large data file for "one time tape" encryption input

Forgot to mention:
The encryption process, the euphoria program, will be DOS based, (or on a dedicated microprocessor that I will program myself) so at no time will a copy of the DVD data be accessible to Windoze. The question is if there is a easy but secure Windoze based way to create the DVD file...

new topic     » goto parent     » topic index » view message » categorize

3. Re: OT: how to securely produce a large data file for "one time tape" encryption input

fizzpopsoft said...

Forgot to mention:
The encryption process, the euphoria program, will be DOS based, (or on a dedicated microprocessor that I will program myself) so at no time will a copy of the DVD data be accessible to Windoze. The question is if there is a easy but secure Windoze based way to create the DVD file...

Hi

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

Andreas

[EDIT: Noise of a floating river or maybe an highway for few hours may give enough random data]

new topic     » goto parent     » topic index » view message » categorize

4. Re: OT: how to securely produce a large data file for "one time tape" encryption input

fizzpopsoft said...

..I want to logically "and" my clear text with ..

Any better ideas, comments..?

Shouldn't this be "xor" or "add" rather than "and" ?

Spock

new topic     » goto parent     » topic index » view message » categorize

5. Re: OT: how to securely produce a large data file for "one time tape" encryption input

Yes, its XOR rather than "and"... just a reversible process of masking plain chars with random data.
Thanks for the wiki link, it describes the pros, cons and history. FWIW, I intend to destroy the DVD via a microwave oven. That cooks / welds / evaporates the metallic layer in the DVD, so thereby destroying the binary 0 and 1's. Try it, and watch the sparks fly!
Using river or traffic noise for random data is a good idea thanks.
I suppose the random number generation would have to be outside of Windoze to be secure. Ah well...

new topic     » goto parent     » topic index » view message » categorize

6. Re: OT: how to securely produce a large data file for "one time tape" encryption input

Please go read these threads then come back here and tell us why you still want to roll your own cryptography:

You should instead rely on industry experts who know what they're doing. I realize that it may be hard to trust third-party software, but there are several free and open source options for strong encryption that are much better than you could ever do yourself:

I can help you with wrapping the relevant C APIs of most any library if that is the case; I would be glad to do it if it means we can add some security to Euphoria programs.

I see some additional downsides to your approach as well:

  • I think it would be incredibly burdensome on your users to require that they A) have a DVD drive, B) put a DVD into a drive to access their own data, and C) not lose that DVD for fear of losing their data. I, for one, would avoid your software like the plague if that were the case. If you want to require a physical key, you might be better off with something like KeyLok.

  • Are you providing the same blob of random data to all users? If Alice knows Bob and Carol both use FizzPopSoft, Alice only has to acquire a copy of Bob's DVD to decrypt Carol's data. Your security relies on the lowest common denominator. Once your shared secret is out in the wild, your encryption is effectively moot. This was the problem with the HDCP master key.

  • Let's assume everything is perfect for the moment, but six months from now you find a Fatal Flaw™ in your algorithm that makes it a trivial process to reverse the encryption. How do you update the algorithm such that you can A) still decrypt the existing data, B) encrypt new data without this flaw, and C) provide your users with an updated copy of the DVD key that works on the data for both A and B?

I'm not trying to cut you down, but I do see you wading into territory best left unexplored.

-Greg

new topic     » goto parent     » topic index » view message » categorize

7. Re: OT: how to securely produce a large data file for "one time tape" encryption input

Thanks Greg,
but yes I do want to "roll my own". I know what my code does, what back-doors might be in someone else's I can't say.
I won't upload it for anyone else because whoever wants it, would be as paranoid as myself and would not want to use it.
Keep in mind, once your info is out there, it can never be retracted. Why make it easy for the data collectors? The one-time-pad (tape) method is the ONLY encryption that is actually uncrackable, assuming unlimited resources is thrown at a decryption effort.
Any encryption where the key is of shorter length than the plaintext, is vulnerable, because there is a relationship.
While I am not in any way an authority on this subject... Without mentioning details that could get me in trouble, I have had 2 years in the armed forces where amongst other things I learned Morse code and had lots and lots of practice with groups of numbers ;)
Here's a funny quote: "Just because I am paranoid, does not mean they are not out to get me"

Thanks,
Alan

new topic     » goto parent     » topic index » view message » categorize

8. Re: OT: how to securely produce a large data file for "one time tape" encryption input

fizzpopsoft said...

but yes I do want to "roll my own". I know what my code does

Can you honestly attest that you know what your code does? We do not know what we do not know, and you will not know if your code can be broken until it is broken.

fizzpopsoft said...

what back-doors might be in someone else's I can't say

The examples I provided have been analyzed repeatedly by many cryptographers for potential back doors and none have ever been found.

fizzpopsoft said...

I won't upload it for anyone else because whoever wants it, would be as paranoid as myself and would not want to use it.

Security through obscurity is no security at all.

fizzpopsoft said...

Keep in mind, once your info is out there, it can never be retracted. Why make it easy for the data collectors? The one-time-pad (tape) method is the ONLY encryption that is actually uncrackable, assuming unlimited resources is thrown at a decryption effort.

That is not true because you are not using a proper one-time pad:

If the key is truly random, is at least as long as the plaintext, is never reused in whole or in part, and is kept completely secret, then the resulting ciphertext will be impossible to decrypt or break.

You are generating the one-time pad and then keeping it static and you are reusing it at some point.

fizzpopsoft said...

Any encryption where the key is of shorter length than the plaintext, is vulnerable, because there is a relationship.

This is also not true. Definitely not true. To date, several encryption algorithms like Blowfish (and Twofish/Threefish), Serpent and Rijndael have no known weaknesses when very strong keys are used (e.g. 256-bit). It would take several lifetimes to crack those algorithms with brute force.

fizzpopsoft said...

While I am not in any way an authority on this subject...

Neither am I. Which is why I can say I will not attempt to secure my clients' data with my own home-made pad lock, regardless of how big it may be.

fizzpopsoft said...

Without mentioning details that could get me in trouble, I have had 2 years in the armed forces where amongst other things I learned Morse code and had lots and lots of practice with groups of numbers ;)

That's good for you. I wish I knew Morse code. But this does not make you a cryptographer.

fizzpopsoft said...

Here's a funny quote: "Just because I am paranoid, does not mean they are not out to get me"

Yes I know that quote. Joseph Heller, Catch-22. However, you may need to consider that your approach is not even wrong.

-Greg

new topic     » goto parent     » topic index » view message » categorize

9. Re: OT: how to securely produce a large data file for "one time tape" encryption input

fizzpopsoft said...

Yes, its XOR rather than "and"... just a reversible process of masking plain chars with random data.
Thanks for the wiki link, it describes the pros, cons and history. FWIW, I intend to destroy the DVD via a microwave oven. That cooks / welds / evaporates the metallic layer in the DVD, so thereby destroying the binary 0 and 1's. Try it, and watch the sparks fly!
Using river or traffic noise for random data is a good idea thanks.
I suppose the random number generation would have to be outside of Windoze to be secure. Ah well...

Just an idea.. why not simply use a dvd with 256 large image files for your random data? Of course to make the key you'd have to read in the file and "process" it a bit before use. When the MIB see your photo collection they will be much less likely to figure it out than if they see, eg, encrypt.dat

Spock

new topic     » goto parent     » topic index » view message » categorize

10. Re: OT: how to securely produce a large data file for "one time tape" encryption input

My code will track what parts of the DVD have been used, to ensure its not reused. Didn't think I needed to mention that.
As I said, I am not an expert. Greg, perhaps you misunderstand my intent; I want my conversations with my wife back home to be private; I want to show the data collectors the digitus impudicus on principle. I am not trying to create a (hopefully) uncrackable method to share with others, because it may not be as secure as is hoped like you said, and if its protection through obscurity then fine, its intended use is for me only.
All I asked for, was a way to produce random numbers where there is no chance of Windoze uploading copies. Useful suggestions were given, thanks.
Cheerio,
Alan

new topic     » goto parent     » topic index » view message » categorize

11. Re: OT: how to securely produce a large data file for "one time tape" encryption input

fizzpopsoft said...

My code will track what parts of the DVD have been used, to ensure its not reused. Didn't think I needed to mention that.

I thought you should have known, as Greg explicitly asked you about it:

ghaberek said...

Are you providing the same blob of random data to all users?

fizzpopsoft said...

As I said, I am not an expert. Greg, perhaps you misunderstand my intent; I want my conversations with my wife back home to be private; I want to show the data collectors the digitus impudicus on principle.

As Greg says, if you were to roll out your own encryption method then you'd fail at this.

That said, if you create a true OTP and use it properly (including destroying it properly), then there's no issue here. But OTP's aren't very popular in part because they're so cumbersome to use.

fizzpopsoft said...

if its protection through obscurity then fine, its intended use is for me only.

Sounds like a rather dangerous attitude. But hey, it is your data after all.

fizzpopsoft said...


All I asked for, was a way to produce random numbers where there is no chance of Windoze uploading copies. Useful suggestions were given, thanks.
Cheerio,
Alan

Alas, this is not enough. http://www.wired.com/2015/03/researchers-uncover-way-hack-bios-undermine-secure-operating-systems/

new topic     » goto parent     » topic index » view message » categorize

12. Re: OT: how to securely produce a large data file for "one time tape" encryption input

Sounds like a PIC chip microprocessor that has no bios is the answer then.
Can we kill this thread now?

new topic     » goto parent     » topic index » view message » categorize

13. Re: OT: how to securely produce a large data file for "one time tape" encryption input

fizzpopsoft said...

Sounds like a PIC chip microprocessor that has no bios is the answer then.
Can we kill this thread now?

Nope.

One last point to mention - even PIC chips can be compromised.

http://www.cl.cam.ac.uk/sps32/mcu_lock.html

http://www.wired.com/2011/08/siemens-hardcoded-password/

http://blogs.scientificamerican.com/guest-blog/researchers-discover-hacker-ready-computer-chips/

(Of course, the barrier is a bit higher, and for your use it may very well still be the better choice. ghaberek just wants to make sure that you are aware of the pros and cons of each.)

new topic     » goto parent     » topic index » view message » categorize

14. Re: OT: how to securely produce a large data file for "one time tape" encryption input

Ok Jim I'll bite long enough to respond to your post.
If a PC bios is assumed hacked, then following Gregs advice earlier would make any data on the PC compromised. So, back to my idea. :)
The chips your links refer to, are not PIC chips; PIC chips have very limited capabilities and resources and its impossible to fit 4Gb into the intended PIC18F4550 chip. BTW, if some of the 256 bytes of PIC EEPROM was unusable(due to a hack resident), it would be noticeable, and could be overwritten anyway! If the 4Gb of random data is produced using said 48MHz PIC, and the XOR encryption and plaintext creation is also done on a PIC.. Then transfer via RS232 serial protocol only the encrypted file to your email capable PC.
The PC can never see the 4GB file or the plaintext.
Those files are stored on USB that only the PIC has access to. The PIC18F4550 chip is USB v2.0 capable, so speed is not an issue either.
Obviously I can look at the enciphered file on the PC before emailing to confirm its only the intended data transferred from the PIC.

new topic     » goto parent     » topic index » view message » categorize

15. Re: OT: how to securely produce a large data file for "one time tape" encryption input

fizzpopsoft said...

If a PC bios is assumed hacked, then following Gregs advice earlier would make any data on the PC compromised.

One should assume this is the case, agreed. But this would also be true for your original idea.

fizzpopsoft said...

The chips your links refer to, are not PIC chips; PIC chips have very limited capabilities and resources ... PIC18F4550 chip.

Actually, Sergei P. Skorobogatov explicitly refers to the PIC18F series as having known vulnerabilities.

fizzpopsoft said...

BTW, if some of the 256 bytes of PIC EEPROM was unusable(due to a hack resident), it would be noticeable,

Skorobogatov refers to several forms of attacks which are non-invasive (that is, not noticeable).

new topic     » goto parent     » topic index » view message » categorize

16. Re: OT: how to securely produce a large data file for "one time tape" encryption input

If you have physical access to the chip then yes its internal program copy protection can be circumvented. Thats not the concern here.
I don't care if my XOR program on the PIC is public, only if the PIC device has been factory shipped with a back door to access data that my application did not intend. This PIC chip has no network capability, so either its shipped with a backdoor that could transfer 4Gb of data through some unknown interface that has the appropriate unknown receiver without me noticing, or its secure for my purpose.
I'll go for the latter. Of course, I assume no-one has physical access to the USB stick containing the 4GB random data either.

new topic     » goto parent     » topic index » view message » categorize

17. Re: OT: how to securely produce a large data file for "one time tape" encryption input

fizzpopsoft said...

If you have physical access to the chip then yes its internal program copy protection can be circumvented. Thats not the concern here.

It's still a matter of probabilities. If your PC's OS and BIOS has been compromised, and they are connected to your PIC somehow (e.g. through USB), then there's a theoretical possibility that the PIC could end up compromised as well.

fizzpopsoft said...

only if the PIC device has been factory shipped with a back door to access data that my application did not intend.

Sadly, this is not entirely impossible. Another article points out a different type of chip (FGPA) for which this did happen.

new topic     » goto parent     » topic index » view message » categorize

18. Re: OT: how to securely produce a large data file for "one time tape" encryption input

I'll generate the random data using a PIC... http://www.romanblack.com/HardRNG/HardRNG1.htm
Then capture the plaintext, again on PIC http://fos.cmb.ac.lk/esl/ps2-keyboard-based-character-logger/
Do the XOR's on the PIC and then use RS232 to send only the enciphered bytes to the PC. With the hardware based RS232 I can build it so see the actual bytes and bits via LED's.
The transfer will be a send initiated by the PIC, so that has control.
Other than physical access issues, I think this will be secure.
Well yes, I could coat my room with foil (Faraday cage), install random coils to generate random heat and magnetism, run a UPS to prevent micro power spikes (keystrokes) from being remotely detected, white noise generator to rattle my windows glass etc etc but I think I'll be OK :)

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu