我的自定义加密算法有多安全? [英] How secure is my custom encryption algorithm?

查看:295
本文介绍了我的自定义加密算法有多安全?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在C#中创建了我自己的非常简单的加密算法,我想知道它是多么的安全。我称之为简单字节密码的算法SBC。本质上,它的作用就像凯撒密码,除了我增加整数(相关字节的值)而不是字母。



有几个原因我决定做这个。首先,我想要一个提供1:1大小比例的算法。换句话说,我希望输出加密长度等于输入文本的长度,而不会增长。我也想要使用我想要的任何字母,数字,字符等,而不用加密大写字母,这是一个本地凯撒密码无法做到的。我希望输出也是一大堆不可打印的字符,就像一个二进制文件。我也想要它快。非常快。我目前的算法能够在比我关心甚至表达的时间更短的时间内完全加密Huckleberry Finn(是的,这是几分之一秒)。



但是真正的问题现在在桌子上...我的算法有多安全?有没有办法测试它?有没有明显的缺陷?先让我先解释一下它的工作原理,然后我会显示代码。



算法实际上很简单,几乎太简单了。我们从我们想要的任意字符串开始,让我们说,在这种情况下,我们选择Stackoverflow。然后我们选择一个密码,这将是猫规则互联网,最后,单个种子/盐值。让我们做31,因为它是我最喜欢的数字。



我的算法首先循环遍历字符串,取每个字母并使用其字节值+密码的当前字母索引字节值+种子整数值。



作为一个模型,它看起来像:

 code>输入字节|密码字节|种子价值| 
45 + 18 + 31 = 94(如果数字超过255,则此数字滚动字节)

然后,我们有一个新的字节值,它可以从数字,一个字母(无论是大写还是不写),一个符号,甚至是不可打印的字符都可以是任何东西。当打印到文件消息这只是一个测试。看起来像:





以下代码为它目前是:

  / ** 
*简单字节密码SBC
*由Gordon创建凯尔·华莱士,Krythic。
* /
public static class SimpleByteCipher
{

public static byte [] EncryptStringToByteArray(string data,string password,uint seed)
{
byte [] bytes = Encoding.ASCII.GetBytes(data);
byte [] passwordBytes = Encoding.ASCII.GetBytes(password);
int passwordShiftIndex = 0; (int i = 0; i< bytes.Length; i ++)
{
bytes [i] =(byte)(bytes [i] + passwordBytes [passwordShiftIndex] + seed) ;
passwordShiftIndex =(passwordShiftIndex + 1)%passwordBytes.Length;
}
返回字节;
}

public static string DecryptByteArrayToString(byte [] data,string password,uint seed)
{
byte [] bytes = data;
byte [] passwordBytes = Encoding.ASCII.GetBytes(password);
int passwordShiftIndex = 0; (int i = 0; i< bytes.Length; i ++)
{
bytes [i] =(byte)(bytes [i] - passwordBytes [passwordShiftIndex] - seed) ;
passwordShiftIndex =(passwordShiftIndex + 1)%passwordBytes.Length;
}
return Encoding.ASCII.GetString(bytes);
}
}

我个人觉得好像很安全。您不仅需要算法,而且需要确切的密码以及用于能够解密加密消息的种子/盐。我只需要知道你们的想法,我在这里遗漏了什么?



想测试你的功夫?尝试解决这个问题:
如果可以破解我

解决方案

移位密码(其中凯撒密码是一个变体)是密码最不安全的类型之一。



我们假设有人意识到您正在使用某种形式的移位密码。经典移位密码只有26个可能的键(对应于拉丁字母表中的26个字母)。您的密钥集较大,因为您的潜在结果字符的域是整个字符集(ASCII,UTF-8,Unicode或其他)。即使你使用unicode,只有大约一百万个可能的键。你使用的整数可以大于这个 - 比如说一百万和一个 - 但是如果你的键只是一个,你会得到相同的效果。如果有人强迫你的加密文本,那么这根本就不需要解密了。



此外,如果解密器推断解密的文本形成了一致的可读字,这将大大减少结果字符集的大小;解密算法不需要考虑所有可能的unicode(或任何你使用的字符集)值,只是人类可以理解的值。



你可以争辩说有人接近这个问题可能不会意识到您正在使用移位密码和浪费时间来弄清楚您正在使用什么,但数百年的密码学研究将移位密码标记为存在的最常见的算法之一。任何值得他/她/盐的解密者都会直接尝试这种方法。


I created my own very simple encryption algorithm in C#, and I was wondering just how secure it really is. I call the algorithm "SBC" which stands for "Simple Byte Cipher". Essentially, it works like a Caesar Cipher, except I increment integers(the value of the associated bytes) instead of letters.

There was a few reasons why I decided to do this. First, I wanted an algorithm that offered an exact 1:1 size ratio. In other words, I wanted the output encryption length to equal the input text's length without any growth. I also wanted to be able to use any letter, number, character, etc that I wanted, without the cipher making everything capital letters, which a native Caesar Cipher cannot do. I wanted the output to also be mostly a mess of unprintable characters, kind of like a binary file. I also wanted it to be fast. Very fast. My current algorithm was able to fully encrypt Huckleberry Finn in less time than I care to even express(yes, it was fractions of a second).

But the real question is on the table now...how secure is my algorithm? Is there a way to possibly test it? Are there any glaring flaws with it? Allow me first to explain how it works, and then I will show you the code.

The algorithm is actually very simple, almost too simple. We start by taking any arbitrary string that we desire, let's say that for this situation we choose "Stackoverflow". We then choose a password, which will be "Cats Rule The Internet", and finally, a single seed/salt value. Let's do 31 because it is my favorite number.

My algorithm starts by looping through the string, taking each letter and using its byte value + the current letter index of the password's byte value + seed integer value.

As a mockup it would look something like:

Input Byte | Password Byte | Seed Value|
    45     +       18      +     31    =  94(this number rolls around for byte if it exceeds 255)

And then, we have our new byte value, which can litterally be anything from a number, a letter(both capital or not), a symbol, or even unprintable characters. When printed to a file the message "This is but a test." looks like:

Here is the code as it currently stands:

    /**
     * Simple Byte Cipher "SBC"
     * Created by Gordon Kyle Wallace, "Krythic".
     */
    public static class SimpleByteCipher
    {

        public static byte[] EncryptStringToByteArray( string data , string password , uint seed)
        {
            byte[] bytes = Encoding.ASCII.GetBytes( data );
            byte[] passwordBytes = Encoding.ASCII.GetBytes( password );
            int passwordShiftIndex = 0;
            for( int i = 0; i < bytes.Length; i++ )
            {
                bytes[ i ] = ( byte )( bytes[ i ] + passwordBytes[ passwordShiftIndex ] + seed );
                passwordShiftIndex = ( passwordShiftIndex + 1 ) % passwordBytes.Length;
            }
            return bytes;
        }

        public static string DecryptByteArrayToString( byte[] data , string password , uint seed)
        {
            byte[] bytes = data;
            byte[] passwordBytes = Encoding.ASCII.GetBytes( password );
            int passwordShiftIndex = 0;
            for( int i = 0; i < bytes.Length; i++ )
            {
                bytes[ i ] = ( byte )( bytes[ i ] - passwordBytes[ passwordShiftIndex ] - seed );
                passwordShiftIndex = ( passwordShiftIndex + 1 ) % passwordBytes.Length;
            }
            return Encoding.ASCII.GetString( bytes );
        }
    }

I personally feel as though it is pretty secure. Not only do you need the algorithm, but you will need the exact password, and the seed/salt that was used to be able to decrypt the encrypted message. I just need to know what you guys think, am I missing anything here?

Want to test your kung fu? Try to crack this: Crack me if you can

解决方案

Shift ciphers (of which the Caesar cipher is a variant) are among the least-secure types of ciphers.

Let's assume that someone were to realize that you were using some form of shift cipher. Classic shift ciphers only have 26 possible keys (corresponding to the 26 letters in the latin alphabet). Your key set is larger, because your domain of potential result characters is the entire character set (ASCII, UTF-8, Unicode, or whatever). Even if you're using unicode, there are only around one million possible keys. An integer you use to shift could be larger than this - say one million and one - but then you get the same effect as if your key was simply one. If someone were to brute force your encrypted text, this would take no time at all to decrypt.

Furthermore, if the decrypter reasoned that the decrypted text formed coherent, readable words, this would drastically reduce the size of the result character set; the decryption algorithm wouldn't have to consider all possible unicode (or whatever character set you use) values, just the ones comprehensible to humans.

You could argue that someone approaching this problem may not realize you're using a shift cipher and waste time trying to figure out what you're using, but hundreds of years of cryptography research has labeled shift ciphers as one of the most commonplace algorithms which exist. Any decrypter worth his/her/its salt would try that approach straightaway.

这篇关于我的自定义加密算法有多安全?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆