Not that this is really specific to windows, but i figured someone would have a more comprehensive explanation. I see how it works... Public key paired with Private key, so that all can Encrypt but only some can decryt, but how is that possible!?

If you have a public key that follows a given algorithm to convert from plaintext to ciphertext, why can't you just reverse engineer the key to get back to plaintext... What am i not seeing? It just seems like you would do the antialgorithm given to you in the public key to be able to decrypt.

Not that this is really specific to windows, but i figured someone would have a more comprehensive explanation. I see how it works... Public key paired with Private key, so that all can Encrypt but only some can decryt, but how is that possible!?

If you have a public key that follows a given algorithm to convert from plaintext to ciphertext, why can't you just reverse engineer the key to get back to plaintext... What am i not seeing? It just seems like you would do the antialgorithm given to you in the public key to be able to decrypt.

All explanations are appreciated.

I have been fooling with this a bit in a little python applet. The algorythm is multi layered, so there is no easy way to reverse encryption bacause it is done in layers - kinda like cyphring a message that is already cyphered - once you take a layer off - how do you know its off?. Only you change things randomly so you use a different cypher each time. This means the only way (I can think of) to reverse the cypher it to try every key. At 128 bit that 3.4X10^38 keys (I think). Also, added to the key is a user password upto 10 characters (in my case). Its not part of the key stored on the system - so even if you got the private key - you are looking at brute forcing the password.

It could be done - but it would take forever and a powerful system. The algorythm is of little help in the effort.

If you have a public key that follows a given algorithm to convert from plaintext to ciphertext, why can't you just reverse engineer the key to get back to plaintext... What am i not seeing? It just seems like you would do the antialgorithm given to you in the public key to be able to decrypt.

All explanations are appreciated.

It is basically mathematically very difficult to do. Some are vulnerable to different types of attacks, depending on how big their keys are, how the keys are made, and how the messages are encrypted.

Here's what happens with public key systems. If I want to send you a signed and secured message, I first encrypt the message with my private key, then with your public key. You receive the message, and decrypt it with *your* private key, then my public key. The public and private keys are mathematically related, but you can't just get one from the other. It takes a public key to decrypt a private key encrypted message, and vice-versa.

I'd recommend reading up on some of them to find out how they really work, and how they really are mathematically "difficult" (I hesitate to say "impossible") to break and essentially impossible to get private keys from with the public key and ciphertext or plaintext.

The other option are symmetric methods, where I give you the key and we both "know" about it. DES, 3DES, and AES are this kind of system.

In general, there are several attacks that are done to attempt to "break" encryption in general:

1. known-plaintext: you know what the original text looks like through other means2. chosen-plaintext: you choose the plaintext to encrypt yourself3. chosen-ciphertext: you can choose the output, but not the plaintext4. dictionary attack: the frequency of some words (a the is of) can help you break encryption based on a repetitive element in the ciphertext5. birthday attack: the probability that any two people in a room have the same birthday is low (apply this to the cryptosystem instead of birthdays )6. man in the middle attack: intercept a session and "pretend" you are the receiving end7. ciphertext only: this basically just means you've gathered the ciphertext of several messages and you need to figure out the key to decrypt them

Each algorithm may have its own vulnerabilities (some of which aren't in my list), for example if you read up on RSA you will find that it is vulnerable to timing attacks, where I can figure out your hardware's timing and "predict" what's going to happen.

Not that this is really specific to windows, but i figured someone would have a more comprehensive explanation. I see how it works... Public key paired with Private key, so that all can Encrypt but only some can decryt, but how is that possible!?

If I want to send you an encrypted message, I use my private key and your public key to encrypt the message. BOTH keys are used to encrypt the message. Your private key is then needed to decrypt the message. Does that make sense? Public/Private key ciphers are important because they solve the 'key distribution' problem.

virtualchaos wrote:

If you have a public key that follows a given algorithm to convert from plaintext to ciphertext, why can't you just reverse engineer the key to get back to plaintext... What am i not seeing? It just seems like you would do the antialgorithm given to you in the public key to be able to decrypt.

All explanations are appreciated.

As Colby mentioned, certain mathematic operations are hard to reverse. The classic example, X % 5 = 2. Can you solve for X?

However, the reason you can't simply use an 'antialgorithm' is because you sill need to know the key. One of the oldest ciphers is called a monoalphabetic substitution cipher. You can create a cipheralphabet using a key....

Then, for each letter in the plaintext, substitute the regular alphabet letter with the cipheralphabet letter, so

commence the attack on the eleventh of september.

becomes,

INKKBMIB TDB HTTHIG NM TDB BJBVBMTD NL SBOTBKABQ.

Think about this for a minute. If you don't know the key, how can you reverse the algorithm? This cipher is weak though - but for a different reason. it vulnerable to a form of attack called frequency analysis and is a common puzzle refered to as a 'cryptogram'.

Here's what happens with public key systems. If I want to send you a signed and secured message, I first encrypt the message with my private key, then with your public key. You receive the message, and decrypt it with *your* private key, then my public key. The public and private keys are mathematically related, but you can't just get one from the other. It takes a public key to decrypt a private key encrypted message, and vice-versa.

the beauty of public key encryption (aka asymmetric encryption) is that you encrypt with one key and decrypt with another. and those two keys are different.

one of the most important thing in encryption is that the security should rely on the key, not the algorithm. if it relies on the algorithm, then like you said, people can simple reverse engineer it and crack the hell out of everything.

most encryption algorithms are well published (RSA, 3DES), so the algorithm itself bears no secret at all. The secret is in the key people hold. Fundamentally, it is all mathematics...

I've been busy, working pretty long hours lately. The company and I are doing well, though

How about you? How's school?

No summer school this time around!

As for school plans, I am still trying to decide whether I want to finish my Masters then work in industry (since things were suppose to be good by now), and when things slow down again, finish a phd and teach at a uni (aka the original plan), or just go ahead and get the phd now. The job market isn’t terrible, but I would still be competing with a lot of vets w/ 10+ years of experience. I am in a 'wait and see' mode right now – I’ll send some phd apps out in a couple of months and see what happens.

I took a job at Cal State Fullerton this past semester. It is ok. Pay sucks, too many meetings, and any crap that Dr. Whoever doesn't want to deal with tends to find itself on my desk. I've spent way too much time doing things that have nothing to do with software engineering – I guess I am a bit bitter now. Fortunately, I am making contacts with a number of people in industry; hopefully, greener pastures are just around the corner.

the password is what the user needs to know to decrypt the message
the key may, or may not, be the same as the password, but it is also needed to decipher the msg.
the rand, short for random, is the information about which cipher was used to initially encipher the plaintext

Let's start with the second method you suggested - it is easier to attack.

In order for someone to decipher the message, they need to have the encrypted message, the password, and the rand (actually, they don't need to 'know' the rand - the information concerning the rand is just passed to them - I'll discuss not knowing the rand later). So where do we put the rand? It can't go in the password - the rand is random! It has to be located within the encrypted message.

So where do we put the rand. We can't do something obvious like encrypting the rand with some known cipher and putting it at the front or end of the message. It would be easy for someone to reverse engineer their own message and find the location. After they figured out which cipher is used to encrypt the rand, you're back to using just a single cipher. Worse yet, they may now know the key!

Don't waste neurons thinking about it though. We don't need transmit the rand. Since we have the password/key, we just go through the first decryption algorithm and then use that result and try each of the 100 remaining possible ciphers. On average, it will take 50 tries to get it. No biggie - computers are fast at this. A good marketing guy will spin doctor this and have people thinking the extra time is just making their data more secure. This is much better then trying to transmit the encrypted rand (at least of the possibilities that I considered).

We could even take this a step further and disregard the rand in your first example. If we had 5 weak ciphers and randomly enciphered the plaintext 3 times with any of the ciphers, we would have a 5^3 combinations of ciphers. 125 is within working range, if you know the key, and it might be possible to use an alpha-beta algorithm to reduce the problem space further.

This technique of enciphering a message multiple time doesn't always improve things though. For example, some ciphers don't provide any extra security when they're used multiple times. You could use a Caesar shift, monoalphabetic substitution or transposition cipher on a message a 1000 times an it wouldn't make a bit of difference. The original weakness just shines right through. Occassionaly, it makes things worse. If anything, I suspect these techniques buy a little more time and help foil automated attacks.

Ok. Had to take a break and switch comps. Gonna test the idea that a super cipher will fool automated attacks. Our super cipher is a monoalphabetic substitiution cipher followed by a caesar shift. Before you read any further, you might want to think about whether this will increase, decrease, or not change the strength of the original cipher.

The automated attack tool is part of CrypTool, which is an interesting program designed to teach encryption. It is a very good tutorial, but not a very good cryptoanalysis tool. It completely floundered w/ the encrypted text I had posted previously. Too short. Confused the poor machine...

Enciphering this paragraph taken from Colby's post.

plaintext wrote:

Here's what happens with public key systems. If I want to send you a signed and secured message, I first encrypt the message with my private key, then with your public key. You receive the message, and decrypt it with *your* private key, then my public key. The public and private keys are mathematically related, but you can't just get one from the other. It takes a public key to decrypt a private key encrypted message, and vice-versa.

Again, the attack failed miserably. In fact, it failed several times using different assumptions for the attack and with different implementations of a monoalphabetic substiution cipher (I even removed all non-letters). Each time the automated attack resulted in exactly the same jibberish, proving beyond any doubt, that Colby's writing contains a subliminal cipher that when combined with even a simple substitution cipher results in an encrypted message that would baffle the NSA's best people. She is that good folks.

Anways, I copied a different text.

plaintext wrote:

Kerry is in the middle of a three-day, 546-mile Fourth of July weekend bus tour through rural Minnesota, Wisconsin and Iowa, just over three weeks before he accepts his party's nomination at the Democratic National Convention.

He planned to meet Saturday with family farmers and ranchers in nearby Independence, Wis., before heading to Dubuque, Iowa, to watch fireworks along the Mississippi River.

On Friday, Kerry attended outdoor rallies in Cloquet, Minn., population 11,200, and Bloomer, Wis., population 3,300, to tout proposals he said would benefit rural Americans.

He talked up his plans to repeal tax cuts for those making more than $200,000, prohibit unfair farming practices such as corporate meatpackers owning livestock more than two weeks before slaughter, and increase renewable fuels from corn, soybeans and other sources.

And, he planned on Saturday to stress his proposals to require food labels to include the product's country of origin and to expand programs that provide financial assistance to farmers to encourage conservation.

"It's time we fought for family farmers," Kerry said in prepared remarks. "The American family farmer grows the safest, lowest priced and finest food on the planet. Our policies should foster an economic climate that helps them compete and succeed in today's global marketplace."

Not bad - this can be finished off quickly. I then took the encrypted text and ran it through a caesar shift and used the automated attack again. Even though I didn't expect this cipher to improve things (see my previous post), I am still surprised - the irrational mind at work.

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum