I like it. My only issue is that this code couldn't ONLY be read by someone with temporal foresight. Any solid hacker and/or mathematician could determine the key's algorithm and project the future message as well. The dark web has plenty of RSA key work-arounds available.

@HAHarvey this is a good point, and the above solution isn't foolproof by any means. But it does combine 'something you know' with 'something you have' in a manner that's not possible without this kind of skillset. As with every solution, foresight should be part of your security model, not the entirety of it.

B II that was why I said I liked it. One of the things I love about cyberpunk and other near future themes is the "one or two steps forward" ideas people have, and how many of them actually happen almost as predicted. (R Talsorian's CP2020: robotic mental-response prosthetics, cigarette-pack sized computers, dermal spray for sealing wounds, and many more)

I don't understand how this works to encode a message. There is no server, there is no authetication; the question asks to devise an encoding (not a cipher) so that being able to see the immediate future is essential in order to read the message. Remember that once encoded the message is static; the encoding must be such that twenty years after encoding the message, readers need to see in the immediate future in order to read it.

If the message is encoded with the "passcode" as the key each time, that means the message will be decrypted every 30 seconds, giving a pretty good vector of attack. Also, the key has to be known when encoding, so the if you have a way to read the key from the system that it should only display 30 seconds later, you also have access to the data. If the information is not encoded like that, this doesn't really answer the question. I mean, it might work for the asker's situation, but it might also not (for instance, a system admin might also have access, which may or may not be a problem)

What if the code changes randomly (for whatever your metric for "randomly" might be), such that the code cannot be predicted? That way even the person who created the message cannot read it without the future sight.

@MichaelS Then the ONLY way to do it is if the next code is based on a quantum interaction (The decay of a radioactive isotope perhaps?). The unique property of these interactions is that the information to predict them does not exist in our universe. However this does not include a way to encrypt the message, just to authenticate the user.

What stops the non-future-vision attacker from saving the message and typing the next code after receiving it?

@JanDorniak the way these encryption dongles work is that the code is only valid while it's displayed on the screen; once the new one comes along, it expires. It's about authentication, not decryption. It's just a way of proving you're you. If you try to do the same thing with the future key by just waiting 30 secs, the key expires and you can't get in. The passcodes from these devices are usually combined with a PIN so that the authentication is a mix of something you know and something you have, but the decryption key will be managed purely by the IT infrastructure; you'll never know it.

@Taxi4Dave the randomness of the code generation isn't an issue; the code has already been generated at the time it's valid. It's the display on the RSA token that hasn't occurred yet. As such, even the most 'random' form of code selection is perfectly predictable because the selection occurs before the code is valid, but is only valid before it's displayed on the token.

Ok, so this relies on authenticating into a secure infrastructure which then shows the message. A valid solution but your answer is unclear. Just look at the amount of comments here assuming it's about some kind of encryption.

@Taxi4Dave this authentication token is in effect a pseudo random number generator with secret seed. A true random number generator is not a valid solution since having the moment in time and the seed it must give deterministic results. So yeah, the seed leaking is an issue but an outside of scope one.

@JanDorniak yes I have noticed that, and I've made the assumption in my answer that people either know what RSA tokens are and have an understanding of IT security models, or have read the attached link. To be frank, I've assumed it was more obvious than it appears to be.

Let us continue this discussion in chat.

But the person can only see 0.1s into the future. The key would have to change every 0.1s to lock out people without futuresight, and any key that you can enter in the space of 0.1s probably isn't very secure.

Back in 1998, RSA tokens were quite stupid regarding time. It was possible to write down say 10 keys generated by the token and afterwards use them one after another as long as they were used in the same order. Not sure if that was ever fixed. I never trusted them again since that time.

@ThomasWeller I'd be very surprised if a bug like that was still unfixed. RSA is still working on their tokens, after all - one of their supported products is a software token app that you can install on your phone.

@ThomasWeller: It's not a bug. Both kinds exist these days. Time-based tokens are now more popular, but sequence-based ones are still common when the device doesn't have a clock, such as a YubiKey. (The advantage is longer battery life.) Often, they even use the exact same algorithm -- the OATH TOTP time-based tokens seen in mobile "authenticator" apps are literally just sequence-based HOTP tokens being generated using (time mod 30) as the sequence number.

That said, I think this answer misses the actual point it should have mode. There's nothing about the algorithm of RSA or OATH tokens that provides this time-based security; someone knowing the original seed can run the algorithm with any timestamp they want and figure out the key earlier. So the really useful piece of technology here is tokens being tamper-proof devices which make it impossible to extract the seed. They don't have to provide 30-sec tokens for the idea to work; it would be the same for them to just reveal the message itself after the internal clock says time X has passed.

Alternative direction: The algorithms are fast, and knowing the seed, they can be run on a computer to immediately produce even tokens for 10 years in the future. So to avoid that you would need to use a slow algorithm; e.g. tell someone to factor a large number (i.e. crack the other kind of RSA key).

This isn't encoding a message; it's authenticating to a device that contains the message. And possessing the dongle is what allows you to do so, rather than any particular details of how it works. This doesn't work for actual encryption, because if you have a message encrypted with a key that you can't compute without knowledge of 30 seconds into the future, you don't need to see into the future to get the key. You just need to wait until you reach it. The idea could be salvaged if you needed to look far enough into the future that waiting is impractical.

What if the authentication is done after the code changes? For example, you type in the code, the device records your answer, then it generates a new random code, and compares it to your answer. It doesn't solve the issue of hacking the equipment, although I think ANY tech-based solution will have that hurdle. I concede that 0.1s being too fast to type is still a problem.