Page History: Simple Encryption
Compare Page Revisions
Page Revision: 2020/06/30 11:56
All communications in public space should really be encrypted.
Various forms of encryption exist and at their simplest they used a "shared secret" - a key string that is used to encrypt and decrypt a message using mathematical progression. Such encryption is termed "symmetrical" as the same key is used to both encrypt and decrypt. It is crucial that the key remain secret for obvious reasons.
Stronger, asymmetrical, encryption uses two separate keys - a public key used to encrypt the data and a private key for decrypting. The public key cannot be used to decrypt the message and so it does not matter that it becomes openly known or shared. The private key must remain secret in the same sense as that for symmetrical encryption.
The
RC4 Encryption and Decryption Functions found elsewhere in this library provide a common form of symmetrical encryption and although RC4 is deprecated it still provides a good level of secrecy with a sufficiently complex key of at least 32 characters (256 bits).
An encryption suite such as RC4 is mathematically intensive and smaller micro-controllers, especially running at lower clock speeds, can struggle to maintain timings in tight spaces purely because it can take a good deal of time to generate the encrypted string or regenerate the original.
If only simple obfuscation is required, you might consider Base64, but that is very easily "un-done". RC4 can be overkill and the timings prohibitive. The below functions use a simple rotating XOR of a shared secret key. It has the advantage of not being weakly-obvious (like Base64) or computationally intensive (like RC4). The main advantage is the routines are very quick and produce a reasonable level of obfuscation - not to the level of RC4, MD5 or BlowFish etc. but certainly enough to prevent clear-text snooping on traffic. A major flaw with the below is that is that the encryption immediately shows traits for similar messages that provide clues to the key for a reasonably competent hacker (rare and not likely listening to the short-range chatter from your air-con controller). Consider the following:
THE QUICK BROWN FOX
6A7C641129613870311469656A633519797A04
j|d)a8p1iejc5yz
the quick brown fox
4A5C441109411850111449454A431519595A24
J\D APIEJCYZ$
Even to the untrained eye, it is obvious the two outputs bear a similarity, especially that case seems to track the opposite of the input. True encryption hides this. If simple obfuscation is required to stop casual, unskilled snoopers this will probably be acceptable but DO NOT use the following functions where good security is required.
Examplesz$=Encrypt$("mary had a little lamb")
z$=Decrypt$(mymessage$)
Preamble CONST KEY$=">4!1x4q3z4+7%4{9?5\3HhH^5$9=6@1~6,7_7|1)7'3]7[9:8<3*8S9I9l7Z1eT0r1"
The Code
Function Encrypt$(a$)
Local Integer n,p
Local b$
p=1
For n=1 To Len(a$)
b$=b$+Hex$(Asc(Mid$(a$,n,1),2) Xor Asc(Mid$(Key$,p,1)),2)
p=p+1:If p>Len(key$) Then p=1
Next
Encrypt$=b$
End Function
Function Decrypt$(a$)
Local Integer n,p
Local b$
p=1
For n=1 To Len(a$) Step 2
b$=b$+Chr$(Val("&h"+Mid$(a$,n,2)) Xor Asc(Mid$(key$,p,1)))
p=p+1:If p>Len(key$) Then p=1
Next
Decrypt$=b$
End Function