On 7 Jan 2015 15:55 -0500, from kevinsisco61...@gmail.com (Kevin):
> Code:
> ;QODE(Quick Offline Data Encryption)
> ;by
> ;Kevin J. Sisco(kevinsisco61...@gmail.com
> ;provides strong encryption for data entered
> ;written in Autoit
> $i = Inputbox(" ", "Enter data")
> $b = StringToBinary($i)
> ;convert to binary
> $s = StringToBinary("the data is now secure")
> ;salt
> $salt = $b+$s
> ;add salt to input
A salt isn't a part of the encryption algorithm, though it's often a
part of a sane cryptosystem implementation. Take a look at for example
RC4; it's been broken, but it's a _dead simple_ example of an
encryption algorithm that for a long time stood the test of the
community. (And it was designed by a well-known and well-renowned
individual in the field of cryptography, who knows and knew the craft.
Ever heard of RSA? One of those guys.)
> $l = BinaryLen($b)
> ;length in bytes
> $br = BitRotate($b, $l)
> ;left bit rotation
So this is basically a Caesar cipher with the rotation amount equal to
the plaintext length? If we assume for a second that the rotation is
per-byte, that will be modulo eight anyway. I can try those eight
combinations by hand if necessary; it'd probably be quicker than
writing up a program to do it for me. Even if the rotation is bitwise
over the entire plaintext input, the value is bounded by 8 * L, where
L is the length in bytes of the plaintext input. For a full DVD (a
little over 4 GiB), that value is about 32 billion, corresponding to
right around 32 bits of key. Anything less than 128 bits of key is
considered short, and 80 bits of key is considered breakable with some
reasonable amount of effort by a determined attacker. Keep in mind
that every single bit added to the key _doubles_ the attacker's
effort, assuming a brute force mode of attack.
> $x = BitXor($br, $l)
> ;xor of rotation and length
> $y = @YEAR
> ;current year
> $r = Random(20, 50)
> ;random number
>
> $formula = $salt+$br+$x+$y+10+32+$r*100
> ;formula
Wait, _what!?!_ Back up a few lines above, you assigned $salt to
_include a representation of the plaintext input!_
> $t = $formula*$formula*$formula*Log($formula)
> ;total
So, for some transformation f(x) on the plaintext (your $formula
assignment), _the output of which includes x_, we have that the
algorithm is f(x)^3 * log(f(x)).
I'm not really up to looking at the math of that right now, and the
intricacies will depend on exactly what Log() in your language is, but
I'm willing to bet that there is a trivial transformation of that
right back to _x_, at which point we essentially have the original
plaintext input. There should _certainly_ be a trivial transformation
back to $formula, which is essentially the same thing.
There isn't even a key in there that I can see, only a salt (which is
included in clear in the output once you allow for the Log()).
> $o = FileOpen("output.txt", 1)
> ;create output file
> FileWriteLine($o, $formula)
> ;store the result
Doesn't this mean that in your implementation, since $formula includes
$salt which includes $b which is a representation of $i (the original
plaintext input), the output file will contain a copy of that
representation of the input? Presumably, StringToBinary() is trivially
reversible.
> FileFlush($o)
> ;flush buffer to disk
> FileClose($o)
> ;close the stream
The above took me all of a few minutes to look over and write up
(mostly slowed down by your rather odd code formatting, causing me to
have to look back and forth several times). And _I am definitely not
an expert in the field_ and _have never used the language you wrote it
in_. I'm just a mostly random guy who happens to do _programming_ for
a living and have an _interest_ in cryptography.
If we may assume that writing $formula to the output file is a simple
bug, and you meant to write $t instead (a very embarassing bug indeed,
but one that does not affect the _cryptography_), then is the entire
security of your algorithm in what you call the "salt"? Is it even in
the _length_ of what you call the "salt"? If so, you should start out
with some basic terminology: _salts are meant to be public_ and are
generally used so that _two plaintexts *hash* to different outputs_ in
order to thwart dictionary or rainbow table attacks on hash values.
They are, roughly, the _hash_ equivalent of an initialization vector.
Here is an exercise for you. Assume that an adversary has access to
the full and complete details of your algorithm. Also assume that the
same adversary can run as many encryption attempts as they want to, on
any plaintext input they choose to. Assume that they have access to
the _particular_ implementation that the entity attempting to secure
communications uses, as well as a copy of the ciphertext of the
communication. Under these circumstances, _what_ property of your
algorithm provides guarantees of _confidentiality_ against reasonable
effort on the part of the attacker?
--
Michael Kjörling • https://michael.kjorling.se • mich...@kjorling.se
OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp
“People who think they know everything really annoy
those of us who know we don’t.” (Bjarne Stroustrup)
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
