How good an encryption algorithm is this?

[Carl Daniel [VC++ MVP]]

Carl -
Is the comparison of the encrypted data with *actual* random noise the
beginning of one of the techniques used for cracking the encryption?
If so, how does it progress?
(see also reply to Steve Friedl)

It certainly could be. I would expect a cyptologist to run some high
powered statistics on the ciphertext, if there's enough of it, to discern if
patterns known to exist in various source texts appear. For example, ASCII
text written in the English language will have certain frequency
distribution characteristics. Any kind of seuqnetial XOR operation will
retain that frequency distribution, it'll just be scrambled up.

-cd

 

[Carl Daniel [VC++ MVP]]

Does always including a NULL terminator weaken an encryption in any
significant way?

Having a common prefix or suffix on a group of messages may help an attacker
break a series of encyrpted messages. With good encryption techniques, this
is not an issue, but it's an Achilles heel of many home-grown encryption
techniques.

-cd

 

[Carl Daniel [VC++ MVP]]

User name / password combination

You should never (or almost never) store passwords with reversible
encryption. Instead, store the username in plaintext and store the password
as a one-way hash. Typically MD5 or SHA(1) are used for this purpose.

Incidentally, another resource you might check out is Crypto++. This is a
C++ class library with implementations of many high-quality crypto
algorithms that you can use to build crypto systems if you don't want to use
the native CryptoAPI. See http://www.eskimo.com/~weidai/cryptlib.html.

-cd

 

[Igor Tandetnik]

Does always including a NULL terminator weaken an encryption in any
significant way?

Probably not. It does give the advantage of known plaintext, but knowing
just one byte of the input is unlikely to help the attacker all that
much. A lot of the data being encrypted has well-known fragments - e.g.
all GIFs begin with GIF89a, all EXEs with MZ and so on. Good encryption
algorithms are designed to withstand known-plaintext attacks.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

 

[Igor Tandetnik]

Well obviously, because they know what byte zero encrypts to, so they
know what bytes were originally zero, by just comparing which ones
are the same as the last byte.

No encryption algorithm worth its salt would consistently encrypt the
same byte to the same value. First, such an algorithm would be trivially
easy to break (e.g. using frequency of occurrence of different letters
in an average English text). Second, it does not hide patterns in the
input - e.g. a long run of the same byte in the input would produce a
long run in the output. This information may be important in and of
itself. Finally, such an algorithm is subject to substitution attacks,
where an attacker can modify one byte of ciphertext to affect one
character of plaintext (imagine replacing No with Yes under a contract
or a purchase order or something). In a strong alorithm, modifying one
bit of ciphertext results in the decoded plaintext being a random
meaningless jumble from the point of modification onward, so the
tampering is hard to miss.

See

http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation

It shows an example of a picture encrypted with an algorithm you
describe (the one that simply performs byte substitution) as well as a
good strong encryption algorithm. Behold the difference.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

 

[Guest]

Yes, I had considered this, BUT:
I do not control the part of the software that decides whether the
re-entered (or "decrypted") password is valid or not. That is SQL Server!
Hence, I *do* need to actually reverse the process.
Like I say, I don't need it to be *absolutely 100%* secure, but I was just
wondering how secure it was - like I've already said, I was conscious that it
wasn't quite as good as a professional API based solution, but I was
wondering *why* it wasn't as good.
I'm never sure how much detailed explanation I need to give as to *why* I
want to do exactly what I want to do, and to what extent I need to persuade,
incite, cajole, or beg people to tell me the information that *I* want to
know, and in order not to be lectured at as to how I 'should' do it - most of
the time it's great, people seem to almost know what I want before I do...
but other times it seems I am bashing my head against a brick wall .... is
there something about my OP that screams out "tell me to use API functions
and don't explain why" ?

 

[Guest]

The reason is that very, very clever people who have a *lot* of

experience in encryption still need to look very carefully at
encryption algorithms before being willing to say how secure they are.
Basically, it's not a field where amateur attempts are likely to be
successful.

Jon - I don't get it. Are you either saying that YOU, Jon Skeet, are someone
who is a "very very clever person who has a lot of experience in encryption"
and that you personally have decided that you're not *willing* to give me an
brief evaluation of the effectiveness of my routine because you want to
remain comparatively clever at encryption, OR, are you thinking "if we keep
repeating the same answer over and over again, eventually he'll get the
impression he doesn't need to know the answer to this" ? If information on
how to encrypt should indeed itself be encrypted, then damnit, give a wrong
answer rather than no answer at all!
Or is it that you can't see why it wouldn't be effective, but you don't want
to tell me this, because it would be unfair of me to put this algorithm to
successful use when lots of people have toiled for many times the number of
hours on "sophisticated" algorithms? (bearing in mind the fact that it
*isn't* likely to be the subject of prolonged attacks just for a single
encryption instance).

As an intelligent person, can you understand how frustrating it is to ask a
question, to be followed up by lots of willing, helpful respondents, who all
make the same general assertion, and when you ask any of them "yes, but why?"
they *all* simply repeat the assertion?
Can you understand how you could also be tempted, because of this, to be
lulled into believing that these people *aren't* in fact particularly
intelligent, when you know full well that they are?

(Thank god for Igor...)

Please don't take offence Jon, none is intended. You've answered a lot of
questions of mine so I know that you're an intelligent guy, but at the end of
the day, I think we're both aware that *you* know that *I* am fairly
intelligent, too - which is why I really, really don't understand why you
made the post you did.

 

[Igor Tandetnik]

"Carl Daniel [VC++ MVP]"

You should never (or almost never) store passwords with reversible
encryption. Instead, store the username in plaintext and store the
password as a one-way hash. Typically MD5 or SHA(1) are used for
this purpose.

.... preferably with salting and stretching, to hinder dictionary
attacks.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

 

[Igor Tandetnik]

bSuccess &= CryptEncrypt(hCryptKey, hCryptHash, TRUE, 0, bData,
&bytesback, bytelen);

Here's your problem. bytesback is an [in, out] parameter. On input,
it's the number of bytes to encrypt. On output, it's the number of
encrypted bytes successfully written. You are passing 0 on input,
asking to encrypt zero bytes.

Oh right....I thought the in parameter was the last parameter, that
I'm passing bytelen to - but it would appear not... thanks for that,
I'll try it.

The last parameter is the size of the buffer, not the size of the data
to be encrypted. It is needed for those rare algorithms where ciphertext
may be larger than plaintext, so the buffer may need to be larger than
the input data it contains.

What, pass NULL to it you mean? What would it not do that it
previously would have done if I'd passed hCryptHash?

Yes, pass NULL. You pass hCryptHash when you need to encrypt and hash
the data simultaneously (this is used in some digital signature
protocols). Since you don't use the hash value, it's a waste of time to
have the function calculate it.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

 

[Jon Skeet [C# MVP]]

Jon - I don't get it. Are you either saying that YOU, Jon Skeet, are someone
who is a "very very clever person who has a lot of experience in encryption"
and that you personally have decided that you're not *willing* to give me an
brief evaluation of the effectiveness of my routine because you want to
remain comparatively clever at encryption,

Heck no.

OR, are you thinking "if we keep
repeating the same answer over and over again, eventually he'll get the
impression he doesn't need to know the answer to this" ? If information on
how to encrypt should indeed itself be encrypted, then damnit, give a wrong
answer rather than no answer at all!

I'm thinking that you still don't seem to "get" that other people have
done the thinking for you. They've designed plenty of crypto algorithms
already. Information on how to encrypt is readily available on the web
- there are plenty of samples around.

Or is it that you can't see why it wouldn't be effective, but you don't want
to tell me this, because it would be unfair of me to put this algorithm to
successful use when lots of people have toiled for many times the number of
hours on "sophisticated" algorithms? (bearing in mind the fact that it
*isn't* likely to be the subject of prolonged attacks just for a single
encryption instance).

I haven't looked at your algorithm in detail, and frankly I don't have
the experience to say whether it's good or not. I could only give you
information about whether or not *I* could break it, and that's not
saying very much.

As an intelligent person, can you understand how frustrating it is to ask a
question, to be followed up by lots of willing, helpful respondents, who all
make the same general assertion, and when you ask any of them "yes, but why?"
they *all* simply repeat the assertion?

We've *given* you the "why" though - the "why" is "because you aren't
trained (as far as we know) in encryption, whereas other people who
designed standard crypto algorithms are". It's also "because lots of
very intelligent people who specialise in this kind of thing have
looked at the standard algorithms, but haven't looked at yours and are
unlikely to".

The way I see it, the assertion is "Use standard algorithms rather than
designing your own" and the reason (which has been posted several
times) is simply "Crypto is hard. You're very unlikely to get it right
- even very highly skilled people get it wrong, which is why there's
peer review. Standard algorithms have the advantage that they've
already been through peer review."

In what way is that simply repeating the assertion?

Can you understand how you could also be tempted, because of this, to be
lulled into believing that these people *aren't* in fact particularly
intelligent, when you know full well that they are?

Not really, to be honest. I think the responses on this thread have
been pretty reasonable.

(Thank god for Igor...)

Please don't take offence Jon, none is intended. You've answered a lot of
questions of mine so I know that you're an intelligent guy, but at the end of
the day, I think we're both aware that *you* know that *I* am fairly
intelligent, too - which is why I really, really don't understand why you
made the post you did.

I suggest you read it again then, along with the other posts. The
answer to your question is definitely there, plain and simple. I'm not
entirely sure which part of it you either don't understand or don't
want to accept.

I suspect no-one here is an expert in cryptography. However, it doesn't
take an expert in cryptography to know that you shouldn't trust an
algorithm which hasn't been vetted thoroughly by a group of experts in
cryptography, because it's very, very unlikely to be as good as the
ones which have been through peer review.

Making a critique of your particular algorithm would be a bit of a
waste of time, to be honest, because the best way to go about things
isn't to patch up whatever problems someone finds with your algorithm -
it's to use a standard algorithm in the first place.

I strongly recommend that instead of trying to get your own algorithm
working, you go back to looking at the crypto API and trying to get
that working instead. I'm sure you'll get a lot more of help on that
front if you post a short but complete program.

 

[Guest]

You've done the right thing in publishing your algorithm because trying to
keep the algorithm secret is no guarantee of cryptographic strength.

That was my thoughts exactly. The random bytes can be changed, and new
features can be introduced like "codepages" to make it so that the same
string will give a different byte string out every time, for instance, I
thought that, as it stands, a lot of the entries are going to be the
encryption of "Integrated Security=SSPI", so they're going to be the same.
Codepages would stop people seeing at a glance which SQL servers use windows
auth. and which use SQL auth....etc. etc. It's just common sense and
confusion as much as sticking to definitive mathematical theory.

But I will wager alot of money that your algorithm is very easy to break by a
cryptographer (of which I'm not one) unless you are a mathematical genius and
have actually come up with a new powerful crypto technique.

OK... I'm always one for a bet that involves skill, are you prepared to
honour that?
My basic terms are as follows:
1) The algorithm is not yet finished, but I must declare when it is, and
when I do so, I must make no further modifications.
2) I must distribute all compiled binaries necessary to run the encryption
(i.e. as a user would) but am not required to distribute any intermediate
data or software I have used to construct the actual source code for my
algorithm. Any "win" by the cryptographer shall be declared void should he
have obtained any of this secret media that wouldn't be distributed to a user
(such as my source code, intermediate data) via prior means, such as internet
hacking of my web server**.
3) The cryptographer must deliver a program capable of deciphering any
password encrypted by *any* release of my DLL*(see below)
4) You must name the cryptographer and time frame in which he is to complete
the task prior to the wager being agreed, but there are no limits on this (or
the number of cryptographers involved or the apparatus they use). If the time
frame is chosen to be more than a day, then the winnings shall not increase
by inflation or interest.
5) We both must provide the other with concrete proof that we have the
amount of money wagered.
6) Either party has the right to supervise the cryptographer during his
decipher attempts but must not impair him.
7) We must both undertake a gentleman's agreement to uphold the wager and
winnings to be delivered via PayPal.

* bear in mind that this is the only thing I'm worried about - laymen
downloading programs in order to be able to crack it. What use is any other
attempt to crack it? It's only going to be storing passwords in HKCU, and a
cryptographer isn't exactly going to want to crack his *own* password, is he?
He's going to want to profit / make a buzz for himself, from a program that
rubbishes my algorithm - the only way to do that is to make the crack
accessible to the layman. This is where the stipulation of the cryptographer
not having access to the actual release of the DLL used comes from, as each
one will be different and have a different key, etc... this won't impair the
functionality as the same one will always be used to decrypt as was used to
encrypt. Hell, it could even generate the random key on installation...

** not that it's in a web directory anyway so don't go trying...

At the end of the day, I'm not worried about an attack by a cryptographer,
I'm more worried about whether it could be cracked by a layman, possibly by
using a program written by a cryptographer. (And please don't simply say
"yes, it could" without explaining how...)
If you'd read my OP, you'd probably have got the gist of the question, which
was that I don't care about this. The question is more, how hard would it be
for a cryptographer to produce a *program* with which a layman (who may have
used the password remember feature) could leave his terminal unlocked for
long enough
for his rival to sneak on to his computer for long enough to run the program
that the "experienced cryptographer" had distributed (for free). Would the
experienced cryptographer be bothered to, or even know to?
And more to the point, how would such a program know which of my home grown
algorithms the data it set out to decipher had been encrypted by???
I could write ten like that... all in different DLLs scattered all over the
place disguised as something innocuous...

This is not meant to trivialise your efforts

See responses to others - do you see what I'm getting at?

 

[Guest]

oh right... yes, i suppose, that is an option -
how do you access comp.* newsgroups?

 

[Doug Harrison [MVP]]

Jon - I don't get it. Are you either saying that YOU, Jon Skeet, are someone
who is a "very very clever person who has a lot of experience in encryption"
and that you personally have decided that you're not *willing* to give me an
brief evaluation of the effectiveness of my routine because you want to
remain comparatively clever at encryption, OR, are you thinking "if we keep
repeating the same answer over and over again, eventually he'll get the
impression he doesn't need to know the answer to this" ? If information on
how to encrypt should indeed itself be encrypted, then damnit, give a wrong
answer rather than no answer at all!
Or is it that you can't see why it wouldn't be effective, but you don't want
to tell me this, because it would be unfair of me to put this algorithm to
successful use when lots of people have toiled for many times the number of
hours on "sophisticated" algorithms? (bearing in mind the fact that it
*isn't* likely to be the subject of prolonged attacks just for a single
encryption instance).

As an intelligent person, can you understand how frustrating it is to ask a
question, to be followed up by lots of willing, helpful respondents, who all
make the same general assertion, and when you ask any of them "yes, but why?"
they *all* simply repeat the assertion?
Can you understand how you could also be tempted, because of this, to be
lulled into believing that these people *aren't* in fact particularly
intelligent, when you know full well that they are?

(Thank god for Igor...)

Please don't take offence Jon, none is intended. You've answered a lot of
questions of mine so I know that you're an intelligent guy, but at the end of
the day, I think we're both aware that *you* know that *I* am fairly
intelligent, too - which is why I really, really don't understand why you
made the post you did.

You need to read a book such as the following, which you can probably find
at your local library:

The Code Book: The Science of Secrecy from Ancient Egypt to Quantum
Cryptography
http://www.amazon.com/exec/obidos/t...f=sr_1_8/102-3274253-6288958?v=glance&s=books

This very readable book will demonstrate why those who tell you that you
won't invent strong encryption on your own are correct to do so, and it will
develop the subject far beyond what is reasonable to expect of newsgroup Q/A
sessions.

You might also want to check out the sci.crypt FAQ:

http://www.faqs.org/faqs/by-newsgroup/sci/sci.crypt.html

 

[Guest]

Hey, we're getting somewhere, thanks Igor...
(inline)

No encryption algorithm worth its salt would consistently encrypt the
same byte to the same value.

Do you reckon that, albeit not the be all and end all, but that if I achieve
that, then it's a big step forward in the right direction?

First, such an algorithm would be trivially
easy to break (e.g. using frequency of occurrence of different letters
in an average English text). Second, it does not hide patterns in the
input - e.g. a long run of the same byte in the input would produce a
long run in the output.

Note that this wouldn't occur in my algorithm, because each byte undergoes a
number of XOR operations given by f(n), where n is the byte number. Hence,
each successive byte undergoes a different number of XOR operations than the
last aswell as different ones, so a string say "00000" will not necessarily
come out as the same byte repeated 5 times.

This information may be important in and of
itself. Finally, such an algorithm is subject to substitution attacks,
where an attacker can modify one byte of ciphertext to affect one
character of plaintext (imagine replacing No with Yes under a contract
or a purchase order or something). In a strong alorithm, modifying one
bit of ciphertext results in the decoded plaintext being a random
meaningless jumble from the point of modification onward, so the
tampering is hard to miss.

Eh? Hard to miss? wouldn't it be easy to miss, as you could just say from
what point the meaningless jumble started, and that's where the tampering
occurred...

And... you're saying that an important principle of a good algorithm is that
each byte affects all the others after it, not just itself?

 

[Guest]

That's a very interesting website, thanks I'll read it.

 

[Igor Tandetnik]

You might also want to check out the sci.crypt FAQ:

http://www.faqs.org/faqs/by-newsgroup/sci/sci.crypt.html

.... especially this one

http://www.faqs.org/faqs/cryptography-faq/snake-oil/

--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

 

[Jon Skeet [C# MVP]]

oh right... yes, i suppose, that is an option -
how do you access comp.* newsgroups?

Use whatever news-server your ISP provides.

 

[Jon Skeet [C# MVP]]

My basic terms are as follows:

2) I must distribute all compiled binaries necessary to run the encryption
(i.e. as a user would) but am not required to distribute any intermediate
data or software I have used to construct the actual source code for my
algorithm. Any "win" by the cryptographer shall be declared void should he
have obtained any of this secret media that wouldn't be distributed to a user
(such as my source code, intermediate data) via prior means, such as internet
hacking of my web server**.

<snip>

It sounds like you're a fan of security through obscurity, which is
another "no-no". Basically, although the *key* should be kept private,
if an algorithm is secure, it shouldn't matter who knows the algorithm
itself. This is important, as given enough time, any software can be
reverse engineered. In other words, the process used to transform
key + encrypted data into plaintext cannot be considered to be secret.

 

[Guest]

OK, thanks I might check it out.

You need to read a book such as the following, which you can probably find
at your local library:

The Code Book: The Science of Secrecy from Ancient Egypt to Quantum
Cryptography
http://www.amazon.com/exec/obidos/t...f=sr_1_8/102-3274253-6288958?v=glance&s=books

This very readable book will demonstrate why those who tell you that you
won't invent strong encryption on your own are correct to do so, and it will
develop the subject far beyond what is reasonable to expect of newsgroup Q/A
sessions.

You might also want to check out the sci.crypt FAQ:

http://www.faqs.org/faqs/by-newsgroup/sci/sci.crypt.html

 

[Guest]

Right, OK. I see what you're saying.
See also inline.

I'm thinking that you still don't seem to "get" that other people have
done the thinking for you. They've designed plenty of crypto algorithms
already. Information on how to encrypt is readily available on the web
- there are plenty of samples around.

Not plenty of good ones, though. Check how many home-grown "XOR" ones there
are on planetsourcecode compared to good, robust, CryptoAPI examples...more
the former than the latter definitely.

We've *given* you the "why" though - the "why" is "because you aren't
trained (as far as we know) in encryption

But that's just it - *as far as you know*. You don't know. How did anyone
get good at encryption, how did the people that do the "training" get good at
it? They have ideas, and put them into practice.
What's more, how do the crackers get good at their skill? Probably by
looking up to other crackers, and analysing how they do their stuff... and
those higher up crackers are probably more into breaking standard algorithms
than mine...I'm merely citing the old adage that the small child who plays
chess against a grandmaster, might just win - due to the fact that he plays
SO badly, none of the grandmaster's standard theories and gameplans work,
because they're all designed to work against other gameplans (which the young
child has no concept of), but still.....

but haven't looked at yours and are
unlikely to".

Again, weak as it is, the point comes back - if they're not likely to look
at it, how do they crack it?

The way I see it, the assertion is "Use standard algorithms rather than
designing your own" and the reason (which has been posted several
times) is simply "Crypto is hard. You're very unlikely to get it right
- even very highly skilled people get it wrong, which is why there's
peer review. Standard algorithms have the advantage that they've
already been through peer review."

The reason for originally posting was that I had tried to get the standard
algorithm working, *and failed*. I did try several times on that first. I
knew my design choice wasn't a good one, but I persisted with it because at
the time it seemed like my *only* choice, and I had thought that I had
explained the fact that I couldn't get the CryptoAPI working sufficient. Igor
has very kindly addressed that, and at the end of the day that's probably
what I'll go with, but since I started out on this tack and spent all of a
whole hour writing the damn thing, I'll finish.

In what way is that simply repeating the assertion?

Well, no - in light of the above paragraph, it possibly just seemed like
that - but you have explained yourself sufficiently now and I thank you for
that.