Sending Encrypted Messages in Morse Code.

[gil]

Gil.

[cockpitbob]

Nice vid Gil.  I like the white board presentation.  It made things nice and clear.

One idea for a OTP that I kind of like is the news paper.  You and your counterpart agree on something like:  the key starts on the first letter in the first column on page-2 of yesterday's Wall Street Journal.  Not as secure as something truly random, but it has exceptional convenience.  Every day the paper boy (do they still exist?) delivers your pad for tomorrow.  I've also heard of using the text from a novel (starts with 2nd paragraph on pg 132, etc).

[gil]

Nice vid Gil.  I like the white board presentation.  It made things nice and clear.

Thanks Bob :-)

Sent from my SM-G928F using Tapatalk

[johno]

A little late to the party here, (only 9 months) but as I started reading this I was going to mention the one time pad site by Dirk Rijmenants, which "Quietguy" already did, which is excellent.  I should also tell you about

http://allworldwars.com/German-Radio-Intelligence-by-Albert-Praun.html

which was written by a bunch of Wehrmacht officers with radio intel experience in both WW-1 and WW-2.  One thing I thought was interesting was their mention of the Polish and Czechs pre-war exercises and when the Nazi's were actually on the move, the Poles and Czech's followed the same plans, complete with call signs and marshalling locations, which the Nazi's had already DF'd!  It's a long read and a little dry at times, but definitely is written by people who know their business.

We were always told in the Army to use wirelines between units in cantonment areas (I've laid miles of WD1-TT).   We were also told that about 11 seconds after pushing the mic button, the Russians could DF your position and have artillery on the way.  When we were in Bavaria for REFORGER, as long as we used speech security devices, there was terrific radio jamming from Czechoslovakia.  As soon as we went back to nonsecure and encryption pads, the jamming stopped.  Nowadays, they have frequency hoppers and I'd love to see how those work!

PS:  CW still does the job!

[gil]

Thanks John, nice insight.
Gil

Sent from my SM-G928F using Tapatalk

[lpwaterhouse]

Hi,

I just discovered the youtube channel and the OTP video drew me here. I'm a bit of a Cryptology nerd and want to chime in on some of the commonly glossed-over details, misconceptions, etc. that are nonetheless surprisingly vital in keeping your communication secret, especially regarding the perfect secrecy of OTPs (which is _far_ more impractical than most people assume). Gil does mention all of the problems, but I think they bear pointing out even more explicitly:

While it is true that a properly generated One-time Pad is information-theoretically perfectly secure, the devil is in the details of that "properly generated". The perfect security ONLY applies when a source of actual, physical, randomness is used, with proper precautions to eliminate biases, etc. The problem is that it is very hard to be sure your source _is_ actually random (Generally nuclear decay, Thermal (Johnson-Nyquist) noise, Avalanche Diodes or the last bit of a microsecond time difference between keystrokes are usually considered "good, as far as we know"). If instead you use any kind of Pseudo-random number generator [PRNG] (e.g. /dev/random, rand(), that formilab site, etc.) then the security guarantees drop from "perfect" to that of an ordinary StreamCipher (in fact "Adding/XORing with an algorithmically generated Key-Stream" is a definition of StreamCipher), subject to the quality of the PRNG, but always lower than "perfect". Some such PRNGs are "cryptographically secure" [CPRNG], meaning that while they aren't "perfect" we _currently_ know no way of breaking them. The majority of PRNGs however are utterly unsuitable for cryptographic purposes, they were designed for statistical properties instead.

So, if you truly want to approach the perfect security of the OTP you MUST use a hardware or "true" RNG [TRNG], and pay attention to whether the cryptographic community considers that particular design "good, as far as we know". Some possible options are http://moonbase.tictail.com/ or https://www.tindie.com/products/WaywardGeek/infinite-noise-true-random-number-generator/.

If you have no access to a TRNG (or you realize that "perfect" is the enemy of "good enough") then you are probably better off using an established cryptographic algorithm, because they a) are likely equal or better than anything you can assemble with a PRNG, even if cryptographically secure, and b) don't share the major drawback of OTPs (or rather: pre-shared key-streams), namely having to _securely_ share a "pad" with the recipient ahead of time, that is at least as long as all messages you ever intend to exchange concatenated (The only advantage of this over communicating securely directly is that it can be shared ahead of time, when circumstances can make it easier, e.g. face to face). There is a good reason even governments/spy agencies don't often use OTPs, exchanging and storing that much highly sensitive "pad" is truly difficult (And then you still have to be extremely careful in using it correctly, or you can easily make non-obvious mistakes that render you encryption surprisingly weak, read up on the "Venona project" for when that happend to the Soviet Union. For example: NEVER EVER repeat the pad! One repetition IS enough to break it, relatively easily even!)

So, what if you only need "good enough"? Meaning something that, according to current research (publicly available only, of course...) would either take longer than the expected life-time of the universe to break, or something that only needs to be secure against non-government adversaries, like your neighbors?

Your best bet is well-established and internationally vetted systems, preferably using public-key algorithms (So you don't even have to exchange the, relatively short, compared to an OTP, key securely), for example RSA with AES.

But those of course require computers and access to cryptographic software (something that many governments consider restricting from time to time...), so you want something that can either be programmed from memory or works without any computer at all, "in the field". I suggest having a look at these two options in particular:

    - CipherSaber-2 (http://ciphersaber.gurus.org/) using RC-4, an easily memorizable algorithm that most programmers can code in a few minutes, with practice. RC-4 itself is considered insecure against determined and knowledgable adversaries, though the modification in CipherSaber-_2_ is likely to alleviate that somewhat. In a SHTF (as opposed to an Orwellian) scenario I wouldn't hesitate to use it.

    - Solitaire (https://www.schneier.com/academic/solitaire/), also known as "Pontifex" (in the "Cryptonomicon" Gil mentioned) working without a computer, using an inconspicuous deck of playing cards. Not much research seems to have gone into the security of Solitaire (though its designer is a respected cryptographer), but its construction suggests it may be vulnerable to the same kind of attacks as RC-4. Still: Certainly good enough against your neighbors. Try it (the password is "GL", which is too short for real use, and I'm not using the optional keying step of setting the Jokers): "LEZVJ RUQLK BCTED"

And last, but not least: In case you want to learn some cryptanalysis and break some ciphers (including a few used by the US army in WW2), have a look at https://www.mysterytwisterc3.org/en/ It can be quite eye-opening...

Regards,
Lawrence

[gil]

Great info, thank you!

I remember reading that AES might have been voluntarily compromised by the NSA, on the random number generator... Also that AES-128 is better than the 256 bit version...

Wouldn't Blowfish be more secure than AES?

Gil

Sent from my SM-G928F using Tapatalk

[lpwaterhouse]

You're thinking Dual_EC_DRBG, which has nothing to do with AES. NSA only reviewed and approved the AES candidate algorithms, they did not have a direct hand in them like with DES (where they secretly made it more secure) or Dual_EC_DRBG (deliberately sabotaged as part of "Bullrun").

As for 128 vs. 256 the one concern is that 256 seems to be slightly weaker (though FAR from broken) against related key attacks, but given its much greater strength overall I'm not worried by that, both options are sensible, I go with 256 if speed is not a major concern.

If I HAD to pick an alternative today I'd go for ChaCha20 (A Stream Cipher, so not fully comparable), Serpent or Twofish (in descending order of preference), but for the moment I trust AES. Much of that is of course personal preference and gut-feeling, but I read the relevant papers too ;-)

[gil]

Thank you.

Gil.

Sent from my SM-G928F using Tapatalk

[KM4WTP]

Sorry for being so late to the thread, but I'm new to the forum and this thread caught my attention because I've been wondering about encryption and ham radio, specifically encryption used in conjunction with SDR radios.

I know none of this legal to do but fun to theoretically think about.

In my corporate life of a voice engineer, working specifically with Cisco Voice in large Enterprise environments.  Many large customers setup encrypted voice for Cisco IP phone to IP communication, the reasons are obvious.

Since the radios are glorified servers specifically designed to act as ham radios.

Could you combine an SDR radio, with built-in encryption so that you could conduct a conversation over the air in a secure manner ??

The other thing that had me thinking along these lines is, I've been thinking of getting a scanner but where I live most of the government agencies use encryption which makes their traffic impossible to hear with a scanner.

[gil]

Technically you can, but not legally of course. Not much left unencrypted these days... Smaller cities with smaller budgets still use older equipment, but larger ones can afford nicer toys...

Gil.

[Xcott]

Hello all,

I teach cryptography at my university and my research area is information security, and I read this thread with great interest.

It is true that a one-time-pad, correctly used, is absolutely theoretically unbreakable.  It's also simple enough to perform by hand (no computers,) and you don't need to trust in the security of some algorithm or hardness of some unsolved problem.

On the other hand, you may notice that barely anyone uses it, despite its simplicity and perfect security, and despite it being well-known for about a century.  That's because of its one unavoidable logistical weakness:  the sender and receiver both need a copy of the key pad in advance, the pad must be at least as long as the message, and each bit of the pad must only ever be used once.

Taken together, that means that you need to make a giant wodge of random key data for all the potential traffic between you and the receiver, and you need to somehow get a copy of that key data to the receiver by a secure channel.  This raises an obvious half-joking question:  if I had a secure channel to hand off a huge amount of key data to the other guy, why not just use that opportunity to hand over the message?  The answer is that you may be able to give someone a DVD of key data today, and not be able to meet with them later, but the point is that we have a pretty onerous key requirement.

That also introduces a serious vulnerability due to the need for intense key discipline.  For example, consider someone who runs out of key symbols and decides to re-use an older part of the pad.  It's very easy for an adversary to catch this, and pull out the transmitted message, by comparing all the sent messages.  The USA actually used this trick to crack Soviet one-time-pad traffic (see the Venona Project for more information.)

In contrast, any other symmetric cipher (like AES) requires a short key that you can simply memorize if you are good at memorizing things.  An AES key is 128 bits; if you can memorize a passphrase of eight dictionary words, you can memorize an AES key, and you don't need to carry any volume of stuff that could present a liability.  Moreover, modern cryptography uses tricks to generate one-time secret keys on the fly, so that nobody needs to memorize any shared secrets at all.  However, none of those tricks can be used with a one-time pad, because of its very stringent key requirements.

Scott K2CAJ

[gil]

Great info Scott, thanks. Certainly, but I would not trust AES. There has been allegations of voluntary weaknesses introcuded to allow possible decoding. I don't remember the details. Bottom line is, I do not understant it enough to be able to determine its security. A one-time-pad is very simple and indeed does not require a computer. In the filed, it would be the simplest way to send an encrypted message. Anyone can learn to do it with pen and paper. The problem is if you have to explain to someone why you carry a long string of seemingly random characters on you... No doubt it would land you in jail forever in many countries, or worse. If I wanted to use a computer encryption cypher I might look at Blowfis/Twofish... That raised a stink when it came out, indicating that it did bother quite a few people... But a cypher sponsored by the NSA, no thanks. Anyways, I have no use for encrypted messaging at this time... If I ever do, and I hope not, a simple one-time-pad would do. Note that you may be able to transfer a long random key file now but not ten years later... For example, you could send a key file encrypted via PGP today by email, but in the event that the internet is no longer available in the future, you would be SOL.

Gil.

[Xcott]

Hi,

I disagree about AES:  the algorithm is actually very transparent and straightforward.  It wasn't designed by the NSA either, nor altered to introduce any weakness.

Also, for a one-time pad you can't send someone the key file encrypted using PGP. If you did that it would no longer be a one-time pad, or to be more specific it would no longer satisfy perfect secrecy.  It would instead be a theoretically breakable cipher with the same weakness as PGP.  For a one-time pad you must transfer the pad material over a channel guaranteed to be secure, no extra encryption allowed.

If I needed a pencil-and-paper cipher I probably wouldn't use a one-time pad, because while the algorithm is super-simple, the key management is horribly complicated, and the one-time pad provides terrible security if anyone is slightly bad at key discipline.  It's an example of a cipher that goes from perfect to awful with just a tiny addition of reality.

[KE5ES]

Five 9 sided dice are a great random 5 number generator for one time pads.  Time consuming but there is a company that produces OTP machines that are stand alone.  https://www.partisanlabs.com/