Help with a line of code

[keoflex]

I need help with line 51.  I had this function built for me and it works exactly for what I want it for.  However I need to translate it to VB.net

 

The main item in question is line 51.  I don't really know what it does specifically the ^ or the ?

$str{$i}=$e&0xE0?chr($e^$k[$j]):chr($e);

 

This code is a section of code from a bigger function that encrypts text based on a key $ky.  I need my vb.net application to run the same function against the database to decrypt the string

 

$ky = 'keyhere';
$str = 'text_to_encrypt';

function myfunc($ky,$str){
//Encrypt Text
	if($ky==''){
		return $str;
	}
	$ky=str_replace(chr(32),'',$ky);
	if(strlen($ky)<{
		echo "error too short";
	}
	$kl=strlen($ky)<32?strlen($ky):32;
	
	$k=array(); //create array
	for($i=0;$i<$kl;$i++){ // 
		$k[$i]=ord($ky{$i})&0x1F; //
	}
	
	$j=0; //counter VAR
	
//cycle through every char in string
	for($i=0;$i<strlen($str);$i++){
		$e=ord($str{$i}); //get ascii value at index $i of string hello, h=0, e=1...
		
		$str{$i}=$e&0xE0?chr($e^$k[$j]):chr($e); //?????????????????????
		echo $e&0xE0?chr($e^$k[$j]):chr($e)."<br />";
		$j++; //add 1 to $j
		$j=$j==$kl?0:$j; // limit count of $j to 15 0-14
		
	}
//END encpypt 
}

Edited May 5, 2017 by keoflex

[Jacques1]

What on earth is this? It looks like an amateur implementation of the Vigenère cipher from the 16th century. That stuff is 500 years old!

 

If you've ever used the same key for multiple plaintexts (which I'm sure you have; appearently it's hard-coded in the script), then anybody can get the plaintext with a simple XOR operation. On top of that, short keys can be found with simple brute force.

 

Unless you're 10 and use this to hide data from your parents, throw away the code and use cryptography for grown-ups. There are standard algorithms like AES which are available in every language and actually work.

Edited May 5, 2017 by Jacques1

[keoflex]

What on earth is this? It looks like an amateur implementation of the Vigenère cipher from the 16th century. That stuff is 500 years old!

 

If you've ever used the same key for multiple plaintexts (which I'm sure you have; appearently it's hard-coded in the script), then anybody can get the plaintext with a simple XOR operation. On top of that, short keys can be found with simple brute force.

 

Unless you're 10 and use this to hide data from your parents, throw away the code and use cryptography for grown-ups. There are standard algorithms like AES which are available in every language and actually work.

 

I appreciate your candid answer.  I have been programming PHP for a long time, but am not very experienced with Encryption.  Would the code below be better suited?  I don't just want to script kiddi this I want to understand it and understand best practices.  Thanks again

 

In this example should I store the bin key to mysql or a txt file behind root? 

Also is it better to keep this as a bin or convert to hex  openssl_random_pseudo_bytes(32); ie

bin2hex( openssl_random_pseudo_bytes(32)

<?php
// DEFINE our cipher
define('AES_256_CBC', 'aes-256-cbc');
// Generate a 256-bit encryption key
// This should be stored somewhere instead of recreating it each time
$encryption_key = openssl_random_pseudo_bytes(32);
// Generate an initialization vector
// This *MUST* be available for decryption as well
$iv = openssl_random_pseudo_bytes(openssl_cipher_iv_length(AES_256_CBC));
// Create some data to encrypt
$data = "Encrypt me, please!";
echo "Before encryption: $data\n";
// Encrypt $data using aes-256-cbc cipher with the given encryption key and
// our initialization vector. The 0 gives us the default options, but can
// be changed to OPENSSL_RAW_DATA or OPENSSL_ZERO_PADDING
$encrypted = openssl_encrypt($data, AES_256_CBC, $encryption_key, 0, $iv);
echo "Encrypted: $encrypted\n";
// If we lose the $iv variable, we can't decrypt this, so:
// - $encrypted is already base64-encoded from openssl_encrypt
// - Append a separator that we know won't exist in base64, ":"
// - And then append a base64-encoded $iv
$encrypted = $encrypted . ':' . base64_encode($iv);
// To decrypt, separate the encrypted data from the initialization vector ($iv).
$parts = explode(':', $encrypted);
// $parts[0] = encrypted data
// $parts[1] = base-64 encoded initialization vector
// Don't forget to base64-decode the $iv before feeding it back to
//openssl_decrypt
$decrypted = openssl_decrypt($parts[0], AES_256_CBC, $encryption_key, 0, base64_decode($parts[1]));
echo "Decrypted: $decrypted\n";
?>

[Jacques1]

This is several orders of magnitude better.

 

However, note that CBC mode is vulnerable to padding oracle attacks if users can interact with the decryption interface. In other words: If there's any way for me to send encrypted text to your application and trigger the decryption function, then you're screwed, because this allows me to systematically guess the plaintext.

 

So CBC is only acceptable when there's no user interaction. A much more robust mode which also protects the integrity of your data is GCM, but this requires either PHP 7.1 or the libsodium extension. If neither is available to you, then CTR would be the next-best choice, because it's at least immune to padding attacks.

 

The key should not be stored in the database, because then it's sitting right next to the encrypted data – which makes the whole thing rather useless. Put the key into a file outside of the document root.

[keoflex]

This is several orders of magnitude better.

 

However, note that CBC mode is vulnerable to padding oracle attacks if users can interact with the decryption interface. In other words: If there's any way for me to send encrypted text to your application and trigger the decryption function, then you're screwed, because this allows me to systematically guess the plaintext.

 

So CBC is only acceptable when there's no user interaction. A much more robust mode which also protects the integrity of your data is GCM, but this requires either PHP 7.1 or the libsodium extension. If neither is available to you, then CTR would be the next-best choice, because it's at least immune to padding attacks.

 

The key should not be stored in the database, because then it's sitting right next to the encrypted data – which makes the whole thing rather useless. Put the key into a file outside of the document root.

Thank you very much!  I have learned a ton in this process!  I will take and apply your suggestions.