Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #12505 > unrolled thread

string encryption

Back to article view | Back to comp.programming

Contents

  string encryption Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-04-28 07:27 -0700
    Re: string encryption Kristjan Robam <he12457@hotmail.com> - 2021-04-28 08:39 -0700
    Re: string encryption David Brown <david.brown@hesbynett.no> - 2021-04-28 19:58 +0200
      Re: string encryption David Spencer <spencer@panix.com> - 2021-04-28 18:00 +0000
        Re: string encryption David Brown <david.brown@hesbynett.no> - 2021-04-28 20:47 +0200
        Re: string encryption Kristjan Robam <rob999999999@yahoo.com> - 2021-04-29 02:26 -0700
      Re: string encryption Kristjan Robam <ya12983@mail.com> - 2021-04-28 12:14 -0700
      Re: string encryption Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-04-28 14:33 -0700
      Re: string encryption Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-04-28 14:39 -0700
    Re: string encryption "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2021-04-28 21:55 +0200
      Re: string encryption Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-04-28 14:33 -0700
        Re: string encryption "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2021-04-29 08:06 +0200
          Re: string encryption David Brown <david.brown@hesbynett.no> - 2021-04-29 09:38 +0200
            Re: string encryption "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2021-04-29 10:00 +0200
            Re: string encryption Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-04-29 22:33 +0100
        Re: string encryption David Brown <david.brown@hesbynett.no> - 2021-04-29 09:37 +0200
          Re: string encryption Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-04-29 06:40 -0700
            Re: string encryption David Brown <david.brown@hesbynett.no> - 2021-04-29 17:01 +0200

#12505 — string encryption

What's the best method for cheap and cheerful string encryption, which takes a plaintext string and a short string as a key, and returns a crypted string? The encrypted text must be a string, so  the encryption must never create a nul character. It might also be best not to create ascii control characters, or non-ascii characters.

[toc] | [next] | [standalone]

#12506

Encryption with php:

Has 3 files below:

func.php

<?php


function rrmdir($dir) {
  $files = array_diff(scandir($dir), array('.','..'));
  foreach ($files as $file) {
    (is_dir("$dir/$file")) ? rrmdir("$dir/$file") : unlink("$dir/$file");
  }
  return rmdir($dir);
}


?>

index.php


<?php
include("func.php");

$dirs = array_filter(glob('*'), 'is_dir');
$fexists=false;
foreach ($dirs as $k=>$v) {
   if($v=="files") $fexists=true;
}

if($fexists==false) {
   mkdir("files", 0755);
}
else {
   rrmdir('files');
   mkdir("files", 0755);
}
?>

<!DOCTYPE html>
<html>
<body>

<form action="krypto.php" method="post" enctype="multipart/form-data">
    File to crypt:
    <p></p>
    <input type="file" name="fileToUpload" id="fileToUpload"/>
    <p></p>
    Text with to crypt: <input type="text" name="passphrase"/>
    <p></p>
    <input type="hidden" name="method" value="crypt" />
    <input type="submit" value="Upload file" name="submit" />

</form>

<p></p>
<p></p>

<form action="krypto.php" method="post" enctype="multipart/form-data">
    File to decrypt:
    <p></p>
    <input type="file" name="fileToUpload" id="fileToUpload">
    <p></p>
    Text with to decrypt: <input type="text" name="passphrase"/>
    <p></p>
    <input type="hidden" name="method" value="decrypt"/>
    <input type="submit" value="Upload file" name="submit"/>
</form>
<p></p>
<p></p>
<p></p>
<p></p>
<p></p>

</body>
</html>

krypto.php


<?php

if(empty($_REQUEST['method'])||empty($_REQUEST['passphrase'])) {
   exit(0);
}

$passphrase=$_REQUEST['passphrase'];

if(strlen($passphrase)<1) exit(0);

$target_dir = "files/";
$target_file = $target_dir . basename($_FILES["fileToUpload"]["name"]);
$uploadOk = 1;

if (file_exists($target_file)) {
    echo "File already exists.";
    $uploadOk = 0;
}
if ($_FILES["fileToUpload"]["size"] > 500000) {
    echo "Your file is too large.";
    $uploadOk = 0;
}
if ($uploadOk == 0) {
} else {
    if (move_uploaded_file($_FILES["fileToUpload"]["tmp_name"], $target_file)) {
    } else {
        echo "There was an error uploading your file.";
    }
}


$inputt = file_get_contents($target_file, true);


if($_REQUEST['method']=='crypt') {
        $inputt = file_get_contents($target_file, true);
        unlink($target_file);
        $cindex=0;

        $outputt="";
        while(true) {
            if($cindex==strlen($inputt)) {
               break;
            }
            $char=chr((ord($inputt[$cindex])+ord($passphrase[($cindex)%strlen($passphrase)]))%256);
            $outputt.=$char;
            $cindex++;
        }

        if (file_exists($newf)) {
            echo "File already exists.";
            exit(0);
        }


        $url  = isset($_SERVER['HTTPS']) ? 'https://' : 'http://';
        $url .= $_SERVER['SERVER_NAME'];
        $url2=$url;
        $url .= $_SERVER['REQUEST_URI'];

        $info = parse_url($url);
        $info["path"]=dirname($info["path"]);

        $newf=$target_dir . basename($_FILES["fileToUpload"]["name"]).'c';
        file_put_contents($newf, $outputt);

        $newurl=$info["path"]."/".$newf;
        echo "<a href='".$url2.$newurl."'>Download</a>";

        chmod($newf, 0777);
} else if($_REQUEST['method']=='decrypt') {
        $inputt = file_get_contents($target_file, true);

        $cindex=0;

        $outputt="";
        while(true) {
            if($cindex==strlen($inputt)) {
               break;
            }
            $char=chr((ord($inputt[$cindex])-ord($passphrase[($cindex)%strlen($passphrase)]))%256);
            $outputt.=$char;
            $cindex++;
        }

        $newf=$target_dir . basename($_FILES["fileToUpload"]["name"]).'decry';

        if (file_exists($newf)) {
            echo "File already exists.";
            exit(0);
        }

        file_put_contents($newf, $outputt);

        $url  = isset($_SERVER['HTTPS']) ? 'https://' : 'http://';
        $url .= $_SERVER['SERVER_NAME'];
        $url2=$url;
        $url .= $_SERVER['REQUEST_URI'];

        $info = parse_url($url);
        $info["path"]=dirname($info["path"]);

        $newurl=$info["path"]."/".$newf;
        echo "<a href='".$url2.$newurl."'>Download</a>";

        chmod($newf, 0777);
}

?>



Kristjan Robam

E-mail: ya12983@@@@@@@ mail.c om
Telephone: 372 6861327 

[toc] | [prev] | [next] | [standalone]

#12507

On 28/04/2021 16:27, Malcolm McLean wrote:
> What's the best method for cheap and cheerful string encryption,
> which takes a plaintext string and a short string as a key, and
> returns a crypted string? The encrypted text must be a string, so
> the encryption must never create a nul character. It might also be
> best not to create ascii control characters, or non-ascii
> characters.
> 

Any preferences for language?  Some languages have such functions in
their standard libraries.  Any need for standards or compatibility, or
is it just for your own use?

You could take your string as a list of bytes, step through it xor'ing
with the key string, then uuencode the result to get a string again.  It
will be okay if you are only encrypting a few short strings with the
same key, and if there is no obvious known pattern in the strings to aid
cracking.

[toc] | [prev] | [next] | [standalone]

#12508

David Brown <david.brown@hesbynett.no> writes:

>On 28/04/2021 16:27, Malcolm McLean wrote:
>> What's the best method for cheap and cheerful string encryption,
>> which takes a plaintext string and a short string as a key, and
>> returns a crypted string? The encrypted text must be a string, so
>> the encryption must never create a nul character. It might also be
>> best not to create ascii control characters, or non-ascii
>> characters.
>> 

>Any preferences for language?  Some languages have such functions in
>their standard libraries.  Any need for standards or compatibility, or
>is it just for your own use?

>You could take your string as a list of bytes, step through it xor'ing
>with the key string, then uuencode the result to get a string again.  It
>will be okay if you are only encrypting a few short strings with the
>same key, and if there is no obvious known pattern in the strings to aid
>cracking.

Or he could do his own homework ...

-- 
dhs spencer@panix.com

[toc] | [prev] | [next] | [standalone]

#12510

On 28/04/2021 20:00, David Spencer wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
>> On 28/04/2021 16:27, Malcolm McLean wrote:
>>> What's the best method for cheap and cheerful string encryption,
>>> which takes a plaintext string and a short string as a key, and
>>> returns a crypted string? The encrypted text must be a string, so
>>> the encryption must never create a nul character. It might also be
>>> best not to create ascii control characters, or non-ascii
>>> characters.
>>>
> 
>> Any preferences for language?  Some languages have such functions in
>> their standard libraries.  Any need for standards or compatibility, or
>> is it just for your own use?
> 
>> You could take your string as a list of bytes, step through it xor'ing
>> with the key string, then uuencode the result to get a string again.  It
>> will be okay if you are only encrypting a few short strings with the
>> same key, and if there is no obvious known pattern in the strings to aid
>> cracking.
> 
> Or he could do his own homework ...
> 

Malcolm is not doing homework - I've known him from various Usenet
groups for something like a decade.  It might be hobby stuff, but when
he asks something, it is a genuine question.  It's nice to see a
programming-related post here rather than yet another post by Tweedledee
or Tweedledum.

[toc] | [prev] | [next] | [standalone]

#12522

I understood, that he wanted help ?
I gave it to the man.





Kristjan Robam

E-mail: ya12983@@@@@@@ mail.c om
Telephone: 372 6861327

David Spencer kirjutas kolmapäev, 28. aprill 2021 kl 21:00:26 UTC+3:
> David Brown <david...@hesbynett.no> writes: 
> 
> >On 28/04/2021 16:27, Malcolm McLean wrote: 
> >> What's the best method for cheap and cheerful string encryption, 
> >> which takes a plaintext string and a short string as a key, and 
> >> returns a crypted string? The encrypted text must be a string, so 
> >> the encryption must never create a nul character. It might also be 
> >> best not to create ascii control characters, or non-ascii 
> >> characters. 
> >> 
> 
> >Any preferences for language? Some languages have such functions in 
> >their standard libraries. Any need for standards or compatibility, or 
> >is it just for your own use? 
> 
> >You could take your string as a list of bytes, step through it xor'ing 
> >with the key string, then uuencode the result to get a string again. It 
> >will be okay if you are only encrypting a few short strings with the 
> >same key, and if there is no obvious known pattern in the strings to aid 
> >cracking.
> Or he could do his own homework ... 
> 
> -- 
> dhs spe...@panix.com

[toc] | [prev] | [next] | [standalone]

#12511

David Brown kirjutas kolmapäev, 28. aprill 2021 kl 20:58:48 UTC+3:
> On 28/04/2021 16:27, Malcolm McLean wrote: 
> > What's the best method for cheap and cheerful string encryption, 
> > which takes a plaintext string and a short string as a key, and 
> > returns a crypted string? The encrypted text must be a string, so 
> > the encryption must never create a nul character. It might also be 
> > best not to create ascii control characters, or non-ascii 
> > characters. 
> >
> Any preferences for language? 

Makes no difference in real life.






Kristjan Robam

E-mail: ya12983@@@@@@@ mail.c om
Telephone: 372 6861327 


Some languages have such functions in 
> their standard libraries. Any need for standards or compatibility, or 
> is it just for your own use? 
> 
> You could take your string as a list of bytes, step through it xor'ing 
> with the key string, then uuencode the result to get a string again. It 
> will be okay if you are only encrypting a few short strings with the 
> same key, and if there is no obvious known pattern in the strings to aid 
> cracking.

[toc] | [prev] | [next] | [standalone]

#12514

On Wednesday, 28 April 2021 at 18:58:48 UTC+1, David Brown wrote:
> On 28/04/2021 16:27, Malcolm McLean wrote: 
> > What's the best method for cheap and cheerful string encryption, 
> > which takes a plaintext string and a short string as a key, and 
> > returns a crypted string? The encrypted text must be a string, so 
> > the encryption must never create a nul character. It might also be 
> > best not to create ascii control characters, or non-ascii 
> > characters. 
> >
> Any preferences for language? Some languages have such functions in 
> their standard libraries. Any need for standards or compatibility, or 
> is it just for your own use? 
> 
> You could take your string as a list of bytes, step through it xor'ing 
> with the key string, then uuencode the result to get a string again. It 
> will be okay if you are only encrypting a few short strings with the 
> same key, and if there is no obvious known pattern in the strings to aid 
> cracking.

[toc] | [prev] | [next] | [standalone]

#12515

On Wednesday, 28 April 2021 at 18:58:48 UTC+1, David Brown wrote:
> On 28/04/2021 16:27, Malcolm McLean wrote: 
> > What's the best method for cheap and cheerful string encryption, 
> > which takes a plaintext string and a short string as a key, and 
> > returns a crypted string? The encrypted text must be a string, so 
> > the encryption must never create a nul character. It might also be 
> > best not to create ascii control characters, or non-ascii 
> > characters. 
> >
> Any preferences for language? Some languages have such functions in 
> their standard libraries. Any need for standards or compatibility, or 
> is it just for your own use? 
> 
It will be written in C++. So the prototypes will be
std::string encrypt(std::string const &plaintext, std::string const &key);
and
std::string decrypt(std::string const &encrtypted, std::string const &key);

I want a short pair of functions.
> 
> You could take your string as a list of bytes, step through it xor'ing 
> with the key string, then uuencode the result to get a string again. It 
> will be okay if you are only encrypting a few short strings with the 
> same key, and if there is no obvious known pattern in the strings to aid 
> cracking.
>
uuencoding is a good idea. The encrypted string needs to be relatively 
robust to being passed about.

[toc] | [prev] | [next] | [standalone]

#12512

On 2021-04-28 16:27, Malcolm McLean wrote:
> What's the best method for cheap and cheerful string encryption, which takes a plaintext string and a short string as a key, and returns a crypted string? The encrypted text must be a string, so  the encryption must never create a nul character. It might also be best not to create ascii control characters, or non-ascii characters.

Looks like a symmetric encryption to me. Any method would do. E.g. 
ChaCha20 cipher. Hash the key to initialize. There are plenty 
implementations of. It is cryptographically strong, computationally 
fast, needs no padding.

If you do not care much about strength, simply use a random generator. 
Hash the key, use it as the seed. xor generated octets to the 
characters. Done.

To make it a C string [why do not you use a language where strings can 
contain anything?] use some re-coding procedure to printable characters, 
e.g. Base64.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#12513

On Wednesday, 28 April 2021 at 20:55:38 UTC+1, Dmitry A. Kazakov wrote:
> On 2021-04-28 16:27, Malcolm McLean wrote: 
> > What's the best method for cheap and cheerful string encryption, which takes a plaintext string and a short string as a key, and returns a crypted string? The encrypted text must be a string, so the encryption must never create a nul character. It might also be best not to create ascii control characters, or non-ascii characters.
> Looks like a symmetric encryption to me. Any method would do. E.g. 
> ChaCha20 cipher. Hash the key to initialize. There are plenty 
> implementations of. It is cryptographically strong, computationally 
> fast, needs no padding. 
>
CHaCha20. Hadn't heard of that. That's the sort of idea I'm looking for. 
> If you do not care much about strength, simply use a random generator. 
> Hash the key, use it as the seed. xor generated octets to the 
> characters. Done. 
>
I'm not overly concerned about strength. If we come under attack from a resourceful
cracker we'll have more things to worry about than these configuration files I'd rather
protect from manipulation.
> 
> To make it a C string [why do not you use a language where strings can 
> contain anything?] use some re-coding procedure to printable characters, 
> e.g. Base64. 
>
I can't change our entire development language just to support a little encryption
routine. It will be a problem to me if the encrypted data is not representable as
a C string.

[toc] | [prev] | [next] | [standalone]

#12518

On 2021-04-28 23:33, Malcolm McLean wrote:
> On Wednesday, 28 April 2021 at 20:55:38 UTC+1, Dmitry A. Kazakov wrote:
>> On 2021-04-28 16:27, Malcolm McLean wrote:
>>> What's the best method for cheap and cheerful string encryption, which takes a plaintext string and a short string as a key, and returns a crypted string? The encrypted text must be a string, so the encryption must never create a nul character. It might also be best not to create ascii control characters, or non-ascii characters.
>> Looks like a symmetric encryption to me. Any method would do. E.g.
>> ChaCha20 cipher. Hash the key to initialize. There are plenty
>> implementations of. It is cryptographically strong, computationally
>> fast, needs no padding.
>>
> CHaCha20. Hadn't heard of that. That's the sort of idea I'm looking for.

https://www.cryptopp.com/wiki/ChaCha20

> I can't change our entire development language just to support a little encryption
> routine. It will be a problem to me if the encrypted data is not representable as
> a C string.

Well, even in C you can pass the length along instead of using NUL as a 
terminator.

It is amazing how things like Base64 and uuencoding are still alive when 
teletypes and modems for which they made sense are long dead. Anyway:

https://en.wikipedia.org/wiki/Uuencoding
https://en.wikipedia.org/wiki/Base64

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#12520

On 29/04/2021 08:06, Dmitry A. Kazakov wrote:
> On 2021-04-28 23:33, Malcolm McLean wrote:
>> On Wednesday, 28 April 2021 at 20:55:38 UTC+1, Dmitry A. Kazakov wrote:
>>> On 2021-04-28 16:27, Malcolm McLean wrote:
>>>> What's the best method for cheap and cheerful string encryption,
>>>> which takes a plaintext string and a short string as a key, and
>>>> returns a crypted string? The encrypted text must be a string, so
>>>> the encryption must never create a nul character. It might also be
>>>> best not to create ascii control characters, or non-ascii characters.
>>> Looks like a symmetric encryption to me. Any method would do. E.g.
>>> ChaCha20 cipher. Hash the key to initialize. There are plenty
>>> implementations of. It is cryptographically strong, computationally
>>> fast, needs no padding.
>>>
>> CHaCha20. Hadn't heard of that. That's the sort of idea I'm looking for.
> 
> https://www.cryptopp.com/wiki/ChaCha20
> 
>> I can't change our entire development language just to support a
>> little encryption
>> routine. It will be a problem to me if the encrypted data is not
>> representable as
>> a C string.
> 
> Well, even in C you can pass the length along instead of using NUL as a
> terminator.
> 
> It is amazing how things like Base64 and uuencoding are still alive when
> teletypes and modems for which they made sense are long dead. 

We still have email attachments, which is the prime use of these
encodings.  (I don't remember using them with modems, but maybe others did.)

> Anyway:
> 
> https://en.wikipedia.org/wiki/Uuencoding
> https://en.wikipedia.org/wiki/Base64
> 

[toc] | [prev] | [next] | [standalone]

#12521

On 2021-04-29 09:38, David Brown wrote:

>> It is amazing how things like Base64 and uuencoding are still alive when
>> teletypes and modems for which they made sense are long dead.
> 
> We still have email attachments, which is the prime use of these
> encodings.  (I don't remember using them with modems, but maybe others did.)

For the same reason: modems had command line interface.

Yes it is not only SMTP, FTP, HTTP. Even new protocols keep on 
pretending to use a command line interfaces, being conveniently ignorant 
of other ASCII control characters beyond CR, LF, they should have 
honored. But who cares?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#12529

David Brown <david.brown@hesbynett.no> writes:

> On 29/04/2021 08:06, Dmitry A. Kazakov wrote:
>> On 2021-04-28 23:33, Malcolm McLean wrote:
>>> On Wednesday, 28 April 2021 at 20:55:38 UTC+1, Dmitry A. Kazakov wrote:
>>>> On 2021-04-28 16:27, Malcolm McLean wrote:
>>>>> What's the best method for cheap and cheerful string encryption,
>>>>> which takes a plaintext string and a short string as a key, and
>>>>> returns a crypted string? The encrypted text must be a string, so
>>>>> the encryption must never create a nul character. It might also be
>>>>> best not to create ascii control characters, or non-ascii characters.
>>>> Looks like a symmetric encryption to me. Any method would do. E.g.
>>>> ChaCha20 cipher. Hash the key to initialize. There are plenty
>>>> implementations of. It is cryptographically strong, computationally
>>>> fast, needs no padding.
>>>>
>>> CHaCha20. Hadn't heard of that. That's the sort of idea I'm looking for.
>> 
>> https://www.cryptopp.com/wiki/ChaCha20
>> 
>>> I can't change our entire development language just to support a
>>> little encryption
>>> routine. It will be a problem to me if the encrypted data is not
>>> representable as
>>> a C string.
>> 
>> Well, even in C you can pass the length along instead of using NUL as a
>> terminator.
>> 
>> It is amazing how things like Base64 and uuencoding are still alive when
>> teletypes and modems for which they made sense are long dead. 
>
> We still have email attachments, which is the prime use of these
> encodings.  (I don't remember using them with modems, but maybe others did.)

Yes.  The "uu" in uuencode and uudecode comes from "Unix to Unix copy"
that was used to distribute email and netnews in the old days.  uucp was
used over modems, some of which needed 7-bit transfers.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#12519

On 28/04/2021 23:33, Malcolm McLean wrote:
> On Wednesday, 28 April 2021 at 20:55:38 UTC+1, Dmitry A. Kazakov wrote:
>> On 2021-04-28 16:27, Malcolm McLean wrote: 
>>> What's the best method for cheap and cheerful string encryption, which takes a plaintext string and a short string as a key, and returns a crypted string? The encrypted text must be a string, so the encryption must never create a nul character. It might also be best not to create ascii control characters, or non-ascii characters.
>> Looks like a symmetric encryption to me. Any method would do. E.g. 
>> ChaCha20 cipher. Hash the key to initialize. There are plenty 
>> implementations of. It is cryptographically strong, computationally 
>> fast, needs no padding. 
>>
> CHaCha20. Hadn't heard of that. That's the sort of idea I'm looking for. 
>> If you do not care much about strength, simply use a random generator. 
>> Hash the key, use it as the seed. xor generated octets to the 
>> characters. Done. 
>>
> I'm not overly concerned about strength. If we come under attack from a resourceful
> cracker we'll have more things to worry about than these configuration files I'd rather
> protect from manipulation.

Are you trying to protect against /manipulation/, or against /reading/
the configuration files?

If it is just manipulation that is concern, have the file as something like:

# Generated configuration file - do not edit!
[foo]
bar = 123
# Configuration file checksum 0123456789abcdef

The final line is the checksum (md5, sha256, whatever) of all the rest
of the file concatenated with a "secret" keystring.

[toc] | [prev] | [next] | [standalone]

#12523

On Thursday, 29 April 2021 at 08:37:29 UTC+1, David Brown wrote:
> On 28/04/2021 23:33, Malcolm McLean wrote: 
> > On Wednesday, 28 April 2021 at 20:55:38 UTC+1, Dmitry A. Kazakov wrote: 
> >> On 2021-04-28 16:27, Malcolm McLean wrote: 
> >>> What's the best method for cheap and cheerful string encryption, which takes a plaintext string and a short string as a key, and returns a crypted string? The encrypted text must be a string, so the encryption must never create a nul character. It might also be best not to create ascii control characters, or non-ascii characters. 
> >> Looks like a symmetric encryption to me. Any method would do. E.g. 
> >> ChaCha20 cipher. Hash the key to initialize. There are plenty 
> >> implementations of. It is cryptographically strong, computationally 
> >> fast, needs no padding. 
> >> 
> > CHaCha20. Hadn't heard of that. That's the sort of idea I'm looking for. 
> >> If you do not care much about strength, simply use a random generator. 
> >> Hash the key, use it as the seed. xor generated octets to the 
> >> characters. Done. 
> >> 
> > I'm not overly concerned about strength. If we come under attack from a resourceful 
> > cracker we'll have more things to worry about than these configuration files I'd rather 
> > protect from manipulation.
> Are you trying to protect against /manipulation/, or against /reading/ 
> the configuration files? 
> 
> If it is just manipulation that is concern, have the file as something like: 
> 
> # Generated configuration file - do not edit! 
> [foo] 
> bar = 123 
> # Configuration file checksum 0123456789abcdef 
> 
> The final line is the checksum (md5, sha256, whatever) of all the rest 
> of the file concatenated with a "secret" keystring.
>
The strings are JSON representing the settings for an editing tool. User can
cache the settings and recall them.  It's user's data, so it's not particularly
secret. But if he reads the string it's giving him an insight into how the tool
works, which might be a good thing but might be a bad thing. However I don't
want him editing the files by hand, seeing what effect it has, and playing with 
it like that. A checksum might be an alternative solution to encryption.

[toc] | [prev] | [next] | [standalone]

#12524

On 29/04/2021 15:40, Malcolm McLean wrote:
> On Thursday, 29 April 2021 at 08:37:29 UTC+1, David Brown wrote:
>> On 28/04/2021 23:33, Malcolm McLean wrote: 
>>> On Wednesday, 28 April 2021 at 20:55:38 UTC+1, Dmitry A. Kazakov wrote: 
>>>> On 2021-04-28 16:27, Malcolm McLean wrote: 
>>>>> What's the best method for cheap and cheerful string encryption, which takes a plaintext string and a short string as a key, and returns a crypted string? The encrypted text must be a string, so the encryption must never create a nul character. It might also be best not to create ascii control characters, or non-ascii characters. 
>>>> Looks like a symmetric encryption to me. Any method would do. E.g. 
>>>> ChaCha20 cipher. Hash the key to initialize. There are plenty 
>>>> implementations of. It is cryptographically strong, computationally 
>>>> fast, needs no padding. 
>>>>
>>> CHaCha20. Hadn't heard of that. That's the sort of idea I'm looking for. 
>>>> If you do not care much about strength, simply use a random generator. 
>>>> Hash the key, use it as the seed. xor generated octets to the 
>>>> characters. Done. 
>>>>
>>> I'm not overly concerned about strength. If we come under attack from a resourceful 
>>> cracker we'll have more things to worry about than these configuration files I'd rather 
>>> protect from manipulation.
>> Are you trying to protect against /manipulation/, or against /reading/ 
>> the configuration files? 
>>
>> If it is just manipulation that is concern, have the file as something like: 
>>
>> # Generated configuration file - do not edit! 
>> [foo] 
>> bar = 123 
>> # Configuration file checksum 0123456789abcdef 
>>
>> The final line is the checksum (md5, sha256, whatever) of all the rest 
>> of the file concatenated with a "secret" keystring.
>>
> The strings are JSON representing the settings for an editing tool. User can
> cache the settings and recall them.  It's user's data, so it's not particularly
> secret. But if he reads the string it's giving him an insight into how the tool
> works, which might be a good thing but might be a bad thing. However I don't
> want him editing the files by hand, seeing what effect it has, and playing with 
> it like that. A checksum might be an alternative solution to encryption.
> 

I'm a fan of letting the user see his/her own data - but that's up to
you.  A checksum here would be a simple and safe way of stopping manual
editing, while keeping the significant benefit of being able to see and
quote the settings (in email, telephone support, etc.).

It also avoids the risk of losing the key and therefore losing all the data.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web