network profile
| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 6 months |
| seen | May 2 at 4:53 | |
| stats | profile views | 1 |
|
Dec 5 |
comment |
How can I validate a hashed password if all I have is another hash? You can try out this solution here which does what you want I think. Also it uses a nonce to prevent replay attacks. |
|
Dec 2 |
comment |
Does a playlist of songs or movies mixed together contain enough random enough for OTP key material? I think there seems to be a bit of a purist attitude towards how random the key material needs to be for these OTPs. If it takes a very long time to generate perfect randomness with a proper random number generator then the entire OTP scheme is not very usable. I think after steps 3 & 4 and the random song/tv/movie data is randomized and sampled, if the key data is unpredictable enough for even many supercomputers to determine the next byte in the key sequence and subsequently decrypt the message then surely that's good enough for practical use. |
|
Dec 2 |
comment |
Does a playlist of songs or movies mixed together contain enough random enough for OTP key material? Thanks @Stephen. Looking at the WAV format, it looks like it won't be particularly useful unless the file is parsed and I only retain the "data subchunk" (orange colour from the diagram) which is the raw sound data as that's going to be more random. Then we'd have to strip out the null bytes too. TV and movie data may be better. |
|
Nov 30 |
comment |
Does a playlist of songs or movies mixed together contain enough random enough for OTP key material? If the whole entropy is generated by the user, e.g. by moving my mouse around, tapping on the keyboard, pulling in data from /dev/random and even plugging in a random number generator dongle, how long would it take to make 200MB of usable random key material? My idea is, there's already a lot of data just sitting on a person's hard drive in the form of entertainment data which is going to be pretty unique already depending on a user's taste in music etc, why not randomize and sample that, then you can generate a lot of key material very quickly. |
|
Nov 30 |
comment |
Does a playlist of songs or movies mixed together contain enough random enough for OTP key material? The thing about 620 million songs might be nothing in cryptogrophy, but remember in WAV format, that might be 45MB on average per song. This is about 26 Petabytes of information or 2.9 x 10^16 bytes of information if my maths is correct. Also if we combine in TV shows/movies at 1200MB per episode/movie in 720P/XviD format then there's over 28 PB of information. Somewhere in there the OTP key is made up of this 28PB of information, in some random order. Who has the resources to find the original OTP key from this information and the ciphertext they intercepted? |
|
Nov 30 |
comment |
Does a playlist of songs or movies mixed together contain enough random enough for OTP key material? I changed step 3. Once all the tv/movie data is joined together, what about randomizing all of the data? The user can provide some input using their mouse/keyboard which will provide some entropy into the randomizing function. Then in step 4 the sampling rate could be user variable too, i.e. it pulls out the 7th byte, then the 3rd byte after that, then the 5th byte after that. Pretty much you'd have an unknown selection of tv/movie data, which is then randomized, then sampled at an unknown rate. 1000 MB of data might only produce 200MB of key data which would be plenty for sending messages. |
|
Nov 29 |
comment |
Does a playlist of songs or movies mixed together contain enough random enough for OTP key material? Also destroying the music/movies after creation of the pad wouldn't be necessary. Because who is to know which combination of movies and music you used to generate it in the first place. It's just a subset of a collection on a hard drive. Sure if the government seizes the computer they'd have a working base of media files to start with. It'll still take them many years on a supercomputer to figure out the individual media files used to make the key. By that point they might've just found the key itself anyway if it was left on the computer. All bets are off if they've got physical access. |
|
Nov 29 |
comment |
Does a playlist of songs or movies mixed together contain enough random enough for OTP key material? Then they've still got to keep trying bits of the ciphertext till they find something meaningful. Even if something 'decrypts' to something meaningful e.g. they get the word 'bob' out, how do they know they got the right key? It could've been a lucky guess. The correct decryption could easily be 'cat'. Surely with all the varying scenes in movies, trees moving in wind, clouds, actors, vehicles, motion, many different landscapes. When the data compiles down to a different coloured pixel which could be translated to a unique byte of data, surely there'd be enough random information there. |
|
Nov 29 |
comment |
Does a playlist of songs or movies mixed together contain enough random enough for OTP key material? You couldn't brute force it without many super computers? First the attacker has to know the key source was made from music and movies in the first place. How are they going to know that? Then the attacker has to know which music and movies were selected at random by the user. There's literally over 620 million songs in existence and over 2.3 million tv/movies titles. Then he has to know the exact combination of those songs/tv/movies that were used to generate the key. Then be able to know the media encoding used for the music/tv/movie and account for all possible combinations of that. |
|
Nov 1 |
comment |
Would this simple encrypted chat program be feasible using One Time Pads? Can I use a CSPRNG library or am I better off getting an actual hardware random number generator? If I also combine in some movements from the user e.g. keyboard strokes and mouse movements in the pad generation process is this a good idea? |
|
Oct 27 |
comment |
Would this simple encrypted chat program be feasible using One Time Pads? So you're saying that after a message has been sent, the pad should be deleted from the sender end's database. Then when the receiver has read the message and confirmed it legit (with HMAC) then the pad can be deleted from the receiver's database as well. Perhaps the content will remain open in the chat window, but when the chat window is closed then it will be flushed from the computer's memory as well. |
|
Oct 26 |
comment |
Would this simple encrypted chat program be feasible using One Time Pads? The US in the past used to use OTPs for the Washington-Moscow hotline, see here a few pages down. Which means at one time they thought the communication was important enough for unbreakable encryption. Maybe they still use something like that today but with more updated equipment. I'm not sure why they would switch to a less secure cipher for important communications like that. |
|
Oct 26 |
comment |
Would this simple encrypted chat program be feasible using One Time Pads? Also watching the NSA guy speak to the panel (link in the Schneier blog) you'll notice he qualifies a lot of his statements. He says things like: "we don't monitor US citizens" (ok but they monitor other countries), we can't do that we need a warrant first and need help from the FBI (but they can if they really wanted to). Most of the questions were about intercepting communications. The NSA aren't doing the intercepting, the ISPs and Telcos are doing that and just sending a copy of all the data to the NSA who can process or decrypt all the data later with their big datacenter. |
|
Oct 26 |
comment |
Would this simple encrypted chat program be feasible using One Time Pads? A few points here, while they say AES is good to protect up to Top Secret level, I don't think that's the highest classification level the US government have. Maybe that's the highest level the public know about. But what encryption are they using to protect their nuclear launch codes or military communications in wartime? Probably a lot stronger encryption. You'll notice they don't publicly give this information out, that's a pretty big hint right there. |
|
Oct 26 |
comment |
Would this simple encrypted chat program be feasible using One Time Pads? If they wanted to communicate with more people then the software would let them generate another database of pads for each person, the software would save it to a removable storage device for them etc, then the only real hassle for the user is delivering it manually to the recipient. Is /dev/random the best/most feasible way for doing the random number generation? If the message is a short message, like "hi" or "hello" is it worth filling up the remaining message (up to 160 characters) with random data so it's less likely they can guess the original plain text? |
|
Oct 26 |
comment |
Would this simple encrypted chat program be feasible using One Time Pads? Ok great, now we're getting somewhere, thankyou! I agree that it is a lot of work to implement properly, but my plan is to design it really well so all the hard and tedious stuff is abstracted away from the user. So basically the software is doing all the hard work in generating the random pads, storing them, integrity checking, sending messages etc. The user would simply have to load up the app, enter in a password which would decrypt the local AES/Twofish encrypted database of pads & messages then they go to sending messages. |
|
Oct 26 |
comment |
Would this simple encrypted chat program be feasible using One Time Pads? @Thomas May be overkill, depends who's using it. What are these "dozens of other issues"? That's what my post is asking. How about an actual answer and listing them? What integrity checks would you use? The reason for OTP, is that it can't be decrypted now or in the future, or by a government that has unpublished knowledge about weaknesses in encryption that are currently in use, or a government having supercomputers that make cracking it trivial. Conspiracy theories aside it would be interesting to implement and also give two parties peace of mind that no-one else could read their messages. |
