Page 2 of 2
Re: simple encryption
Posted: Fri Jan 24, 2025 11:53 am
by moricode
STARGÅTE wrote: Fri Jan 24, 2025 9:32 am
It's a pleasure, indeed. Your new code has now other bugs:
- On line 15, "b -1", you decrease the loop limit each round by one byte. So the latter bytes are encrypted just one or two rounds, not three.
- The "key" structure is now a byte array and as your round-loop has only three rounds (plus an extra byte) you use only 4 bytes of your 12 bytes key!
- What is the sense of line 18-20, where you change the key itself, when the byte position is odd?
Thanks for the review.
My aim to design a NOT Common XOR that can transform easily and also increase security compare to ordinary XOR,
1. Every byte of msg was adapt to XOR with different key , different from the key input by user
2. Even if people get encrypted msg and key , he couldn't simply XOR to see the original text
How to do , with the same procedure , by changing to the outer loop number i , and b parameter , so you have custom XOR that i can't decrypt (not easily at least
)
it is not consistent XOR , so the last few byte is to confuse others that it is "ordinary XOR" , but it is NOT .
The line 18-20 is to achieve that , even you know the key , but it is not "ordinary XOR" , so it wouldn't work by simply XOR , the key is changing it self
This is just junior approach to design a "Self Adapt Key Transforming XOR" algorithm.
Re: simple encryption
Posted: Fri Jan 24, 2025 12:28 pm
by STARGÅTE
So, you think out an algorithm for an "encryption" where the security is not important (as you said), but you want to increase its complexity to the increase security? Now I'm out as well.
Just make XOR multiple times or with different keys does not increase the "security" if you do it byte-by-byte.
When you look at your input and output, you still have a one-to-one correlation between input character and output character, e.g. the space character is always maped to ©.
The quick brown fox jumps over the lazy dog 12 times a day
Ýáì©øüàêâ©ëûæþç©ïæñ©ãüäùú©æÿìû©ýáì©åèóð©íæ»©ýàäìú©è©íèð䑄
A simple occurrence analysis of the encrypted bytes and a comparison with the occurrence of letters in the English language would be enough to decrypt the message without knowing the key or the algorithm.
With this background a "simple" XOR would lead to the same result.
Re: simple encryption
Posted: Sat Jan 25, 2025 10:18 pm
by Piero
SPH wrote: Fri Jan 24, 2025 12:27 amOther:
Coucou
Code: Select all
Procedure.s dec_enc(txt$,key.w)
For i=1 To Len(txt$)
unProtected_txt2$+Chr(Asc(Mid(txt$,i,1))!key)
Next
ProcedureReturn unProtected_txt2$
EndProcedure
txt$="Coucou les amis, j'espère que vous allez bien !!!"
Debug txt$
Debug dec_enc(txt$,149)
Debug dec_enc(dec_enc(txt$,149),149)
Re: simple encryption
Posted: Mon Jan 27, 2025 12:06 am
by SPH
@Piero :
thx you.
(More ship than my method ?)
Re: simple encryption
Posted: Mon Jan 27, 2025 4:51 pm
by Piero
@SPH :
Was a half joke to write your method with fewer lines
This is better and faster:
Code: Select all
Procedure.s dec_enc(txt$,key.w)
Protected txt2$,i,n=Len(txt$)
For i=1 To n
txt2$+Chr(Asc(Mid(txt$,i,1))!key)
Next
ProcedureReturn txt2$
EndProcedure
Edit: I was curious, but cannot see HexaScrabble.com
Re: simple encryption
Posted: Mon Jan 27, 2025 5:15 pm
by skywalk
I agree with others. There are existing tried and true encryption algo's available to PB or external C-libs if not implemented.
Keep coding
Re: simple encryption
Posted: Sat Feb 01, 2025 12:34 am
by Piero
Code: Select all
Procedure.s enc_dec(text.s,pass.s,de.s= "e") ; "d" = decrypt
Protected ssl,Output$,p.s=URLEncoder(pass)
ssl = RunProgram("/usr/bin/openssl","aes-256-cbc -A -"+de+" -a -k "+
p,"",#PB_Program_Open|#PB_Program_Write|#PB_Program_Read)
If ssl
if de="d"
WriteProgramStringN(ssl,text)
else
WriteProgramStringN(ssl,URLEncoder(text))
EndIf
WriteProgramData(ssl,#PB_Program_Eof,0)
While ProgramRunning(ssl)
If AvailableProgramOutput(ssl)
Output$ + ReadProgramString(ssl)
EndIf
Wend
CloseProgram(ssl)
EndIf
if de="d":Output$=URLDecoder(Output$):EndIf
; EndIf should be here? ;)
ProcedureReturn Output$
EndProcedure
Debug enc_dec("text","pass")
Debug enc_dec(enc_dec("text","pass"),"pass","d")
Note: use the homebrew version for stronger encryption
Re: simple encryption
Posted: Sat Feb 01, 2025 7:32 am
by tj1010
Use AES 256 CBC with crypto-safe PNRG(already in PB) for key and IV, and AES 256 XTS with PNRG for SLC/MLC/TLC/QLC NAND and platter storage.
SHA3 for hashing(already in PB)
ECDH and RSA 4096 or AES 256 GCM for key exchange and PKI via openssl or windows->bcrypt/CNG(CSP now deprecated).
When NIST and TLS finalize ML-KEM, SLH-DSA, and ML-DSA and it hits openSSL this will all change.. I think the AHEAD for them is already in Chromium and Safari. This is post-quantum cryptography.
ChaCha20 will remain the bleeding edge for stream ciphers cause I haven't seen any type of NIST standardization for stream ciphers besides mentions of Y-00.
A lot of the xor stuff like is used here is typically used in malware packers and loaders, and analysts usually have it defeated within hours through weak key management.. I'm not sure how something's security can be stated if nobody qualified has tried to attack it; A lot of the stuff posted here likely doesn't need key-space-brute-forced..
Re: simple encryption
Posted: Sat Feb 01, 2025 9:16 am
by Piero
Well, for me it was just an exercise with "PB runprogram and old AES PARAMETERS" (grr…)
It's very easy and quick to modify it for files (instead of "stdin stdout") but on Mac you can just create an encrypted (and writable) .dmg image with Disk Utility…