Cryptography in the age of quantum computers (split from Why does a quantum computer render RSA useless?)

[Carrock]

Slightly off topic, but defeating quantum decryption is quite simple (human stupidity excepted) and the technique has been known since at least 1882.

From Wikipedia

In cryptography, the one-time pad (OTP) is an encryption technique that cannot be cracked, but requires the use of a single-use pre-shared key that is larger than or equal to the size of the message being sent.

A couple of phones, each with say 64GB identical one time code storage and no ability to change the software without physical access should be fine for a few years of communication.

For obvious reasons, adverts for increasingly powerful phones and encryption rarely mention this.

[KJW]

2 hours ago, Carrock said:

Slightly off topic, but defeating quantum decryption is quite simple (human stupidity excepted) and the technique has been known since at least 1882.

From Wikipedia

In cryptography, the one-time pad (OTP) is an encryption technique that cannot be cracked, but requires the use of a single-use pre-shared key that is larger than or equal to the size of the message being sent.

A couple of phones, each with say 64GB identical one time code storage and no ability to change the software without physical access should be fine for a few years of communication.

For obvious reasons, adverts for increasingly powerful phones and encryption rarely mention this.

But one-time pad keys are not public keys.

 

[swansont]

!

Moderator Note

Split. This is more than slightly off-topic

 

[Sensei]

15 hours ago, Carrock said:

A couple of phones, each with say 64GB identical one time code storage and no ability to change the software without physical access should be fine for a few years of communication.

..sending random data to the recipient would result in desynchronization. They would be in different bytes of the key..

15 hours ago, Carrock said:

In cryptography, the one-time pad (OTP) is an encryption technique that cannot be cracked, but requires the use of a single-use pre-shared key that is larger than or equal to the size of the message being sent.

The keyword here is "single-use", which is virtually impossible. Sooner or later you will end up sending the same key again.

Plaintext with all zeros XOR key = key. Basic human communication in ASCII has few zeros (8th bit will be mostly 0), but binary data has many zeros, e.g. an ISO image can have an area with 32 KB of zeros, UTF-16 usually have 0 byte every two bytes, etc. etc.

The key must be generated in some way. Discovering the key generation algorithm increases the chance of decoding the signal.

Instead of brute force WiFi password hacking, you can check the device manufacturer and see how they created the password creation algorithm..

https://www.google.com/search?q=access+point+wifi+password+generation+algorithms

or this:

https://hackaday.com/2016/01/27/tp-links-wifi-defaults-to-worst-unique-passwords-ever/

"TP-LINK’s WiFi Defaults To Worst Unique Passwords Ever"

 

15 hours ago, Carrock said:

In cryptography, the one-time pad (OTP) is an encryption technique that cannot be cracked, but requires the use of a single-use pre-shared key that is larger than or equal to the size of the message being sent.

Desynchronization forced by a third party or transmission errors will require resending the data.

 

Edited January 7 by Sensei

[Sensei]

15 hours ago, Carrock said:

A couple of phones, each with say 64GB identical one time code storage and no ability to change the software without physical access should be fine for a few years of communication.

If someone has an iOS older than 14.8, Pegasus can instantly remotely hack it, as long as they have Internet access:

https://www.macrumors.com/2021/09/13/ios-14-8-zero-click-exploit-pegasus/

If someone has an iOS older than 16.6.1, Pegasus can instantly remotely hack it, as long as they have Internet access:

https://medium.com/@letshackit/apples-ios-16-6-1-update-fixes-severe-zero-day-exploit-used-to-install-pegasus-spyware-dca4aafd25ef

 

Edited January 7 by Sensei

[StringJunky]

To be a subject of Pegasus software, for what it costs to implement, one would need to be a very high value target. I'm under no worries about Pegasus.

Quote

Citing a 2016 price list, the New York Times reported the NSO Group charged its customers $650,000 to infiltrate 10 devices, plus an installation fee of $500,000,
The NYT report also stated that much like a traditional software company, the NSO Group prices its surveillance tools by the number of targets, starting with a flat $500,000 installation fee.
According to a commercial breakdown, NSO charges government agencies $650,000 to spy on 10 iPhone users; $650,000 for 10 Android users; $500,000 for five BlackBerry users; or $300,000 for five Symbian users — on top of the setup fee.

https://timesofindia.indiatimes.com/business/india-business/pegasus-snooping-how-costly-is-the-israeli-spyware/articleshow/84893498.cms

 

[Sensei]

1 hour ago, StringJunky said:

To be a subject of Pegasus software, for what it costs to implement, one would need to be a very high value target. I'm under no worries about Pegasus.

Once the zero-day is revealed to public, anyone can use it against devices with older vulnerable versions of the operating system or software.

You can get root on any Windows 7 and 8 system (including Server and Enterprise versions) with default settings and on any Mint Linux system..

 

1 hour ago, StringJunky said:

Citing a 2016 price list, the New York Times reported the NSO Group charged its customers $650,000 to infiltrate 10 devices, plus an installation fee of $500,000,

..it just tells that their customers are idiots..

 

Edited January 7 by Sensei

[Carrock]

6 hours ago, Sensei said:

..sending random data to the recipient would result in desynchronization. They would be in different bytes of the key..

 

I don't see why anything but noise would cause desynchronization.

To (re)synchronise if frequently needed, use a predefined part of the key (different each time) to send e.g. ZZZZZZZZZZafdc74cf to indicate the next byte used for message encryption. Fairly straightforward software could be used to find which part of the key decodes as ZZZZZZZZZZ.

 

 

1 hour ago, Sensei said:

The keyword here is "single-use", which is virtually impossible. Sooner or later you will end up sending the same key again.

Goods e.g. a key can be sent by trusted courier which has been possible for a few thousand years. This code, like any other, relies on physical security.

Any finite length one time code code will, if generated often enough, eventually repeat by random chance, in this case (64GB) after at least many billion uses, but that doesn't assist decoding.

 

 

 

7 hours ago, Sensei said:

 

The key must be generated in some way. Discovering the key generation algorithm increases the chance of decoding the signal.

 

Instead of brute force WiFi password hacking, you can check the device manufacturer and see how they created the password creation algorithm..

 

A recommended way here is to use a noisy reverse biased diode in avalanche mode and an analogue to digital converter to generate the code. With some care, the slight preferential bias for some digits can be made far too small to be useful for decoding. I don't think knowing the algorithm would help.

 

6 hours ago, Sensei said:

If someone has an iOS older than 14.8, Pegasus can instantly remotely hack it, as long as they have Internet access:

........

If someone has an iOS older than 16.6.1, Pegasus can instantly remotely hack it, as long as they have Internet access:

.....

 

The important issue here is to realize that crude and cheap is much better than sophisticated and expensive. An ancient phone with no internet access and only text and voice can't be hacked without physical access, assuming the phone designer was honest and competent. Some software would be needed for de- and encryption. If the phone was stolen, all its one time code would be compromised but not other phones with different one time code.

 

 

7 hours ago, Sensei said:

Desynchronization forced by a third party or transmission errors will require resending the data.

If you want to annoy a spook monitoring your comms, send this plain text message first.

'To make sure you get the full list of our secret agents in Britain, I'll send it 10 times.

Naturally you use different parts of the one time code for each message and actually send it 1000 times.

 

One time code is inconvenient but has its advantages.

I recall many years ago hearing people droning out interminable lists of numbers on short wave radio; my first experience of one time code.

 

 

[Sensei]

13 minutes ago, Carrock said:

I don't see why anything but noise would cause desynchronization.

We have two phones or two computers. They open a connection from one to the other over a potentially hostile environment, the Internet. One uses socket send(), the other uses recv(), and then vice versa. One byte sent, one byte received, so the sender's counter is incremented accordingly. The same thing happens to the counter on the receiving machine. All good if there is no MITM which intercepts the connection and injects the bytes in the middle of the stream, resulting in machines being at different offsets in the secret key..

 

19 minutes ago, Carrock said:

To (re)synchronise if frequently needed, use a predefined part of the key (different each time) to send e.g. ZZZZZZZZZZafdc74cf to indicate the next byte used for message encryption. Fairly straightforward software could be used to find which part of the key decodes as ZZZZZZZZZZ.

..all is good as long as there is no MITM, then why encrypt and decrypt messages..?

 

21 minutes ago, Carrock said:

The important issue here is to realize that crude and cheap is much better than sophisticated and expensive. An ancient phone with no internet access and only text and voice can't be hacked without physical access, assuming the phone designer was honest and competent. Some software would be needed for de- and encryption. If the phone was stolen, all its one time code would be compromised but not other phones with different one time code.

.. anyone can pretend to send a text message from any GSM number. The receiver sees the "correct phone number", but from MITM or whomever in the case of SMS/MMS. The message that will be decoded into the trash and offset to the secret key on the receiver of such a message will have a different value than on the 2nd machine.

Edited January 7 by Sensei

[Carrock]

3 minutes ago, Sensei said:

We have two phones or two computers. They open a connection from one to the other over a potentially hostile environment, the Internet. One uses socket send(), the other uses recv(), and then vice versa. One byte sent, one byte received, so the sender's counter is incremented accordingly. The same thing happens to the counter on the receiving machine. MITM intercepts the connection and injects the byte(s) in the middle of the stream, resulting in them being at different offsets in the secret key..

 

For some forgotten reason I originally assumed you meant random data from the sender rather than malicious interference.

Malicious interference can disrupt any communication; the important point with O.T.C. is never ever  reuse it for any reason.

[Sensei]

38 minutes ago, Carrock said:

Malicious interference can disrupt any communication;

That's why people invented checksums, hash functions, digital signatures.. and a pretty simple project for a first-year student with just socket(), listen(), accept(), connect(), send(), recv(), close(), fopen(), fread(), possibly select() (for async), which has just raw data, will grow to a pretty complex.. just to detect malicious data in our stream..

38 minutes ago, Carrock said:

the important point with O.T.C. is never ever  reuse it for any reason.

In the worst-case scenario, if you send an (unused yet) offset to the secret key to the other party (to regain any encrypted communication after introduction of any malicious data in the stream), MITM could use DoS/DDoS to cause the secret key to be depleted on the machines.. 64 GB / 100 Mbps (12.5 MB/s) = ~ 5243 seconds..

Edited January 7 by Sensei

[Carrock]

44 minutes ago, Sensei said:

That's why people invented checksums, hash functions, digital signatures.. and a pretty simple project for a first-year student with just socket(), listen(), accept(), connect(), send(), recv(), close(), fopen(), fread(), possibly select() (for async), which has just raw data, will grow to a pretty complex.. just to detect malicious data in our stream..

In the worst-case scenario, if you send an (unused yet) offset to the secret key to the other party (to regain any encrypted communication after introduction of any malicious data in the stream), MITM could use DoS/DDoS to cause the secret key to be depleted on the machines.. 64 GB / 100 Mbps (12.5 MB/s) = ~ 5243 seconds..

O.T.C. isn't particularly suited for sending vast amounts of data or for the internet as I hinted at in my preference for cheap and crude over sophisticated and expensive. Fairly secure encryption is pretty much necessary for the internet.

To avoid rather than solve these problems, if phones with their metadata are also unsuitable, one of many alternatives: frequency hopping radio with one time code to set the frequencies.

This is very hard to jam and a fairly secure version is widely used by the military and other clandestine communicators. One time code isn't normally practical for large numbers of users. Probably civilians couldn't get a license as governments like to eavsdrop.

 

[Carrock]

There's an arms race between security and hacking in encryption and I hadn't really thought about the internet, computers and O.T.C.

The securely encoded data in O.T.C. is actually encode once, send, copy or read many. Only the copies of the O.T.C. key must be held securely.

 

So send an encrypted file via internet to another computer as described by Sensei. DOS attacks etc don't deplete O.T.C. as the same encrypted data can be resent. For best security copy the file to a computer which never has internet access. Plug in a memory stick with a copy of the one time key used by the originator. Run a simple program which uses the one time key to decrypt the file. Don't save the decrypted data , unplug the stick and switch off the computer when finished.

 

The O.T.C. doesn't need to be significantly larger than the total of all files sent.

[Carrock]

On 1/7/2024 at 4:40 PM, StringJunky said:

To be a subject of Pegasus software, for what it costs to implement, one would need to be a very high value target. I'm under no worries about Pegasus.

Nor me.

However, hacking my email enough (more if competent) for my ISP to change my password and inconvenience me was a lot simpler/cheaper.

It's rather sad that mentioning public domain work by Frank Miller (1882) and Hedy Lamarr (1942 patent) is considered worth this response.

[StringJunky]

7 hours ago, Carrock said:

Nor me.

However, hacking my email enough (more if competent) for my ISP to change my password and inconvenience me was a lot simpler/cheaper.

It's rather sad that mentioning public domain work by Frank Miller (1882) and Hedy Lamarr (1942 patent) is considered worth this response.

Is that principally by  social engineering methods?

[Carrock]

13 hours ago, StringJunky said:

Is that principally by  social engineering methods?

I don't know but probably just some saddo annoying me. It's the first time anyone's ever made even a token effort to hack me AFAIK.

Updating my password on my various devices was tedious but probably very low security risk.