simple encryption

[moricode]

It's a pleasure, indeed. Your new code has now other bugs:

1. 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.
2. 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!
3. 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.

[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.

[Piero]

Other:

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)

[SPH]

@Piero :

thx you.
(More ship than my method ?)

[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

[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

[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

[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..

[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…