Visual cryptography is a popular solution for image encryption.

Using secret sharing concepts, the encryption procedure encrypts a secret image into the so-called shares which are noise-like secure images which can be transmitted or distributed over an untrusted communication channel. Using the properties of the human visual system to force the recognition of a secret message from overlapping shares, the secret image is decrypted without additional computations and any knowledge of cryptography. Visual cryptographic solutions operate on binary or binarized inputs. Therefore, natural (continuoustone) images must be first converted into halftone images by using the density of the net dots to simulate the original gray or color levels in the target binary representation. Then, the halftone version of the input image is used instead of the original secret image to produce the shares. The decrypted image is obtained by stacking the shares together. Because binary data can be displayed either as frosted or transparent when printed on transparencies or viewed on the screen, overlapping shares that contain seemingly random information can reveal the secret image without additional computations or any knowledge of cryptographic keys. However, due to the nature of the algorithm, the decrypted image is darker, contains a number of visual impairments, and most of visual cryptography solutions increase the spatial resolution of the secret image. In addition, the requirement for inputs of the binary or dithered nature only limits the applicability of visual cryptography.

isual Cryptography 1. Introduction Visual cryptography (VC) is a method of encrypting a secret image into shares such that stacking a sufficient number of shares reveals the secret image. Shares are usually presented in transparencies. Each participant holds a transparency. Most of the previous research work on VC focuses on improving two parameters: pixel expansion and contrast. In this paper, we studied the cheating problem in VC and extended VC. We considered the attacks of malicious adversaries who may deviate from the scheme in any way. EVEN with the remarkable advance of computer technology, using a computer to decrypt secrets is infeasible in some situations. For example, a security guard checks the badge of an employee or a secret agent recovers an urgent secret at some place where no electronic devices are available. In these situations the human visual system is one of the most convenient and reliable tools to do checking and secret recovery. Therefore, Naor and Shamir [19] invented the visual cryptography (VC) in which a secret image (printed text, picture, etc.) is encrypted in a perfectly secure way such that the secret can be decoded directly by the human visual system. 1.1 Project Scope 1.2 This approach is applied for sending of any image secretly to receivers. Participant of out sider inserted fake shares or images are detected and corresponding participant is valid or not is verified. In visual cryptography we propose three cheating methods and apply them on existent VC or EVC schemes. Although, the revealed secret is an image, our attacks are not like the attacks against watermarks, such as the Stir mark attack, which makes watermarks undetectable. Our attacks are to reveal fake images to cheat honest participants. Our attacks are more like the man-in-the-middle attack in cryptography. In fact, our attacks are very general for all kinds of VCSs without cheatingprevention mechanism. We propose three cheating methods against VC or EVC schemes.

2. Overall description 2.1 Product Perspective Visual cryptography is a popular solution for image encryption. Using secret sharing concepts, the encryption procedure encrypts a secret image into the so-called shares which are noise-like secure images which can be transmitted or distributed over an untrusted communication channel. Using the properties of the human visual system to force the recognition of a secret message from overlapping shares, the secret image is decrypted without additional computations and any knowledge of cryptography. 2.2 Product Feature developer applications This application discusses some of the concepts on which these systems are built. The Visual cryptography is modulated in to 5 main parts There is a login process for every participant to view the secret image. Encoding the image in to shares and send it to the participant. Decoding the image by stacking the n shares or fewer than n i.e. k shares where (k<=n). Verification is done by verifying the original share of the first participant with the verification share of the second participant. All GUI components are created using AWT Swings for user friendly.

2.3 User Classes and Characteristics Using this product user can prevent the cheating in VCS from the intruders in sharing the original image from one participant to another. The participant will first login to the window; it shows a message open the secret image. Participant has to select the image and open the file, next it asks for the verification image to open. We have to decode the process by adding the original image shares and verification image shares. To verify whether the shares are genuine are not we have to stack the share1 of original image by verify2 of verification image for participant and vice versa for second participant. if both participants have genuine shares the original image is opened. 2.4 User Documentation In our user manual we are going to keep the information regarding our product, which can be understandable by a new person who is going to use it. If a new person is using it, online help will be provided in that. We are going to explain each and every step clearly about our product so that any user can easily understand it. 3. System Features In this mechanism we have 5 modules Security & Login Module Encoding the Image Verification Module Decoding the Image User Interface & Manual Security & Login Module To provide security for the application we designed a login page so that unauthorized person cannot open the window.

Encoding the image Here we are encoding by selecting the secret image and dividing the image in to shares i.e 2 shares, share1 & share2 and we are selecting the another verification image and dividing in to 2 shares as verify1 & verify2.

Verification Module We have to verify the image by stacking the share1 of 1st participant and verify2 of 2nd participant we will get a verification image1 and flag1 is enabled and in the same way share2 of 2nd participant & verify1 of 1st participant is stacked together so that we will get the verification image2 and flag2 is enabled. After the flags are enabled if we click on them they display the messages as participant1 & 2 verifications are successful Decoding the Image After verifying the participants we have to stack the share1 & share2 and decode the secret image. User Interface & Manual This module is specially designed for the GUI components for the participant to interact with the window efficiently. Its a user friendly module. 4. External Interface Requirements 4.1 User Interfaces This application include GUI standards or product family style guides that are to be followed, screen layout constraints, standard buttons and functions that will appear on every screen, error message display standards, and so on

A colleague recently asked if I could help him understand the Diffie-Hellman key exchange protocol without digging through the math. My answer was Yes I can, but not easily. Doing so requires a few diagrams because, in this particular case, a picture is worth at least a thousand words! First things first why do we care about Diffie-Hellman? Simply stated, if you are involved in any sort of Virtual Private Network (VPN), you are probably using Diffie-Hellman, even if you didnt realize it. If that VPN is operating on the IPSec standard, then Diffie-Hellman is certainly in use. To follow the standards trail for key management in IPSec, we begin with the overall framework called Internet Security Association and Key Management Protocol (ISAKMP; see RFC 2408). Within that framework is the Internet Key Exchange (IKE) protocol (see RFC 2401). IKE relies on yet another protocol known as OAKLEY and it uses Diffie-Hellman as described in RFC 2412. It is an admittedly long trail to follow, but the result is that Diffie-Hellman is, indeed, a part of the IPSec standard. While it is true that a given VPN system could be in use for years without its administrators understanding DiffieHellman, I have found that an understanding of underlying protocols helps a great deal when trouble-shooting a system. That is not to say that we have to completely understand the math behind the protocol. In fact, I have worked with encryption systems for years even though any mathematical operation more difficult than balancing a checkbook baffles me completely. There are bona fide experts in the field of encryption mathematics. When they say a system is mathematically secure, I take them at their word. This frees me to concentrate on other issues such as keeping the system operational and discerning the finer points of cooking a steak on the Bar-B-Q things that really matter!

The Diffie-Hellman algorithm, introduced by Whitfield Diffie and Martin Hellman in 1976, was the first system to utilize public-key or asymmetric cryptographic keys. (Note: Evidence shows that Comm-Electronics Security Group (an arm of the U.K. government) may have invented the concept of asymmetric key 6 years before D-H. The CESG papers were classified for 20 years, but Diffie-Hellman figured it out on their own without the information in those papers.) These systems overcome the difficulties of private-key or symmetric key systems because key management is much easier. In a symmetric key system, both sides of the communication must have identical keys. Securely exchanging those keys has always been an enormous issue. As one example, the National Security Agency has an entire fleet of its own planes manned by armed couriers to shuttle around the approximately fifteen tons of paper based symmetric key used by the United States Government every year. Businesses simply do not want to mess with that. Asymmetric key systems alleviate that issue because they use two keys one called the private key that the user keeps secret and one called the public key that can be shared with the world. Unfortunately, the advantages of asymmetric key systems are overshadowed by speed they are extremely slow for any sort of bulk encryption. Today, it is typical practice to use a symmetric system to encrypt the data and an asymmetric system to encrypt the symmetric keys. That is precisely what Diffie-Hellman is capable of doing and does do when used for key exchange as described here. Diffie-Hellman is not an encryption mechanism as we normally think of them in that we do not typically use it to encrypt data. Instead, it is a method to securely exchange the keys that encrypt data. Diffie-Hellman accomplishes this secure exchange by creating a shared secret (sometimes called a key encryption key) between two devices. The shared secret then encrypts the symmetric key (or data encryption key i.e. DES, Triple DES, CAST, IDEA, Blowfish, etc.) for secure transmittal. The process begins when each side of the communication generates a private key (depicted by the number 1 in Figure 1). Each side then generates a public key (number 2), which is a derivative of the private key. The two systems then exchange their public keys. Each side of the communication now has their own private key and the other systems public key (number 3). Noting that the public key is a derivative of the private key is important the two keys are mathematically linked. However, in order to trust this system, you must accept that you cannot discern the private key from the public key. Because the public key is indeed public and ends up on other systems, the ability to figure out the private key from it would render the system useless. This is one area requiring trust in the mathematical experts. The fact that the very best in the world have tried for years to defeat this and failed bolsters my confidence a great deal. I should also explain the box labeled Optional: CA Certifies Public Key. It is not common, but the ability does exist with the Diffie-Hellman protocol to have a Certificate Authority certify that the public key is indeed coming from the source you think it is. The purpose of this certification is to prevent Man In the Middle (MIM) attacks. The attack consists of someone intercepting both public keys and forwarding bogus public keys of their own. The man in the middle potentially intercepts encrypted traffic, decrypts it, copies or modifies it, re-encrypts it with the bogus key, and forwards it on to its destination. If successful, the parties on each end would have no idea that there is an unauthorized intermediary. It is an extremely difficult attack to pull off outside the laboratory, but it is indeed possible. Properly implemented Certificate Authority systems have the potential to disable the attack.

Figure 1 Key Generation and Exchange Once the key exchange is complete, the process continues. An important feature of the Diffie-Hellman protocol is its ability to generate shared secrets an identical cryptographic key shared by each side of the communication. Figure 2 depicts this operation with the DH Math box (trust me, the actual mathematical equation is a good deal longer and more complex). By running the mathematical operation against your own private key and the other sides public key, you generate a value. When the distant end runs the same operation against your public key and their own private key, they also generate a value. The important point is that the two values generated are identical.

Figure 2 Shared Secret Creation At this point, the Diffie-Hellman operation could be considered complete. The shared secret is, after all, a cryptographic key that could encrypt traffic. That is very rare however. The reason being that the shared secret is, by its mathematical nature, an asymmetric key. As with all asymmetric key systems, it is inherently slow. If the two sides are passing very little traffic, the shared secret may encrypt actual data. Any attempt at bulk traffic encryption requires a symmetric key system such as DES, Triple DES, IDEA, CAST, Blowfish, etc. In most real applications of the DiffieHellman protocol (IPSec in particular), the shared secret encrypts a symmetric key for one of the symmetric

algorithms, transmits it securely, and the distant end decrypts it with the shared secret. Figure 3 depicts this operation. Because the symmetric key is a relatively short value as compared to bulk data, the shared secret can encrypt and decrypt it very quickly. Speed is not so much of an issue with short values. Which side of the communication actually transmits the symmetric key varies. However, it is most common for the initiator of the communication to be the one that transmits the key. I should also point out that some sort of negotiation typically occurs to decide on the symmetric algorithm, mode of the algorithms (i.e. Cipher Block Chaining, etc.), hash functions (MD5, SHA1, etc) key lengths, refresh rates, and so on. That negotiation is not a part of DiffieHellman, but it is an obviously important task since both sides must support the same schemes for encryption to function. This also points out why key management planning is so important and why poor key management so often leads to failure of systems.

Figure 3 Encrypting, Passing, and Decrypting the Symmetric Key Once secure exchange of the symmetric key is complete (and note that passing that key is the whole point of the Diffie-Hellman operation), data encryption and secure communication can occur. Figure 4 depicts data encrypted and decrypted on each end of the communication by the symmetric key. Note that changing the symmetric key for increased security is simple at this point. The longer a symmetric key is in use, the easier it is to perform a successful cryptanalytic attack against it. Therefore, changing keys frequently is important. Both sides of the communication still have the shared secret and it can be used to encrypt future keys at any time and any frequency desired.

Figure 4 Encrypted Data Transmission The use of Diffie-Hellman greatly reduces the headache of using symmetric key systems. These systems have astounding speed benefits, but managing their keys has always been difficult to say the very least. Because the steps we have just gone through happen in a matter of a second or two and are completely transparent to the user, ease of use could not be better provided it works. The good news is that it almost always does work. Understanding the underlying protocol only becomes necessary in the rare case that it doesnt. The complete Diffie-Hellman Key Exchange Diagram Follows:

Figure 5 - Complete Diffie-Hellman Key Exchange Process

Diffie-Hellman Key Exchange

Your Ad Here
Diffie-Hellman (D-H) key exchange is a cryptographic protocol that allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communications channel. This key can then be used to encrypt subsequent communications using asymmetric key cipher. Synonyms of Diffie-Hellman key exchange include:

Diffie-Hellman key agreement Diffie-Hellman key establishment Diffie-Hellman key negotiation exponential key exchange

The scheme was first published publicly by Whitfield Diffie and Martin Hellman in 1976, although it later emerged that it had been invented a few years earlier within GCHQ, the British signals intelligence agency, byMalcolm J. Williamson but was kept classified. In 2002, Hellman suggested the algorithm be called DiffieHellman-Merkle key exchange in recognition of Ralph Merkle's contribution to the invention of public-key cryptography (Hellman, 2002). Although Diffie-Hellman key agreement itself is an anonymous (non-authenticated) key-agreement protocol, it provides the basis for a variety of authenticated protocols, and is used to provide perfect forward secrecy in Transport Layer Security's ephemeral modes.

Contents
[hide]

1 History of the protocol

2 Description

2.1 Chart

3 Security

3.1 Authentication

4 References 5 See also

6 External links

History of the protocol

Diffie-Hellman key agreement was invented in 1976 during a collaboration between Whitfield Diffie and Martin Hellman and was the first practical method for establishing a shared secret over an unprotected communications channel. Ralph Merkle's work on public key distribution was an influence. John Gill suggested application of the discrete logarithm problem. It had been discovered by Malcolm Williamson of GCHQ in the UK some years previously, but GCHQ chose not make it public until 1997, by which time it had no influence on research in academia. The method was followed shortly afterwards by RSA, another implementation of public key cryptography using asymmetric algorithms. In 2002, Martin Hellman wrote: The system...has since become known as Diffie-Hellman key exchange. While that system was first described in a paper by Diffie and me, it is a public key distribution system, a concept developed by Merkle, and hence should be called 'Diffie-Hellman-Merkle key exchange' if names are to be associated with it. I hope this small pulpit might help in that endeavor to recognize Merkle's equal contribution to the invention of public key cryptography. [1] U.S. Patent 4,200,770, now expired, describes the algorithm and credits Hellman, Diffie, and Merkle as inventors.

Description
Image:Diffie-Hellman-Schlsselaustausch.png Diffie-Hellman key exchange

The simplest, and original, implementation of the protocol uses the multiplicative group of integers modulo p, where p is primeand g is primitive root mod p. Modulo (or mod) means that the integers between 0 and p 1 are used with normal addition, subtraction, multiplication, and exponentiation, except that after each operation the result keeps only the remainder after dividing by p. Here is an example of the protocol: Alice
Sec Calc Calc

Bob
Sec

1. Alice and Bob agree to use a prime number p=23 and base g=5. 2. Alice chooses a secret integer a=6, b then sends Bob (ga mod p)

p, g a g mod p (gb mod p)amod p =

a

p, g

gbmod p (ga mod p)bmod p

56 mod 23 = 8.

3. Bob chooses a secret integer b=15, then sends Alice (gb mod p)

515 mod 23 = 19.

4. Alice computes (gb mod p)a mod p

196 mod 23 = 2.

5. Bob computes (ga mod p)b mod p

815 mod 23 = 2.

Both Alice and Bob have arrived at the same value, because gab and gba are equal. Note that only a, b and gab = gba are kept secret. All the other values are sent in the clear. Once Alice and Bob compute the shared secret they can use it as an encryption key, known only to them, for sending messages across the same open communications channel. Of course, much larger values of a, b, and p would be needed to make this example secure, since it is easy to try all the possible values of gab mod 23 (there will be, at most, 22 such values, even if a and b are large). If p were a prime of at least 300 digits, and a and b were at least 100 digits long, then even the best algorithms known today could not find a given only g, p, and ga mod p, even using all of mankind's computing power. The problem is known as the discrete logarithm problem. Note that g need not be large at all, and in practice is usually either 2 or 5. Here's a more general description of the protocol:

1. Alice and Bob agree on a finite cyclic group G and a generating element g in G. (This is usually done long before the rest of the protocol; g is assumed to be known by all attackers.) We will write the group G multiplicatively. 2. Alice picks a random natural number a and sends ga to Bob. 3. Bob picks a random natural number b and sends gb to Alice. 4. Alice computes (gb)a. 5. Bob computes (ga)b. Both Alice and Bob are now in possession of the group element gab, which can serve as the shared secret key. The values of (gb)a and (ga)b are the same because groups are power associative. (See also exponentiation.)

Chart
Here is a chart to help simplify who knows what. (Eve is an eavesdroppershe watches what is sent between Alice and Bob, but she does not alter the contents of their communications.) Let s = shared secret key. s = 2 Let a = Alice's private key. a = 6 Let b = Bob's private key. b = 15 Let g = public base. g=5

Let p = public (prime) number. p = 23 Alice

knows doesn't know knows

Bob
doesn't know knows

Eve
doesn't know

p = 23 base g = 5 a=6 5 mod 23 = 8 5b mod 23 = 19 196 mod 23 = 2 8b mod 23 = 2 196 mod 23 = 8b mod 23 s=2
6

b = 15

p = 23 base g = 5 b = 15 5
15

a=6

p = 23 base g = 5

a=6 b = 15 s=2

mod 23 = 19

5 mod 23 = 8 5b mod 23 = 19 19a mod 23 = s 8b mod 23 = s 19a mod 23 = 8b mod 23

5a mod 23 = 8 815 mod 23 = 2 19a mod 23 = 2 815 mod 23 = 19a mod 23 s=2

Note: It should be difficult for Alice to solve for Bob's private key or for Bob to solve for Alice's private key. If it isn't difficult for Alice to solve for Bob's private key (or vice versa), Eve may simply substitute her own private / public key pair, plug Bob's public key into her private key, produce a fake shared secret key, and solve for Bob's private key (and use that to solve for the shared secret key. Eve may attempt to choose a public / private key pair that will make it easy for her to solve for Bob's private key).

Security
The protocol is considered secure against eavesdroppers if G and g are chosen properly. The eavesdropper ("Eve") must solve the Diffie-Hellman problem to obtain gab. This is currently considered difficult. An efficient algorithm to solve the discrete logarithm problem would make it easy to compute a or b and solve the DiffieHellman problem, making this and many other public key cryptosystems insecure. The order of G should be prime or have a large prime factor to prevent use of the Pohlig-Hellman algorithm to obtain a or b. For this reason, a Sophie Germain prime q is sometimes used to calculate p=2q+1, called a safe prime, since the order of G is then only divisible by 2 and q. g is then sometimes chosen to generate the order q subgroup of G, rather than G, so that the Legendre symbol of ga never reveals the low order bit of a. If Alice and Bob use random number generators whose outputs are not completely random and can be predicted to some extent, then Eve's task is much easier.

The secret integers a and b are discarded at the end of the session. Therefore, Diffie-Hellman key exchange by itself trivially achieves perfect forward secrecy because no long-term private keying material exists to be disclosed.

Authentication
In the original description, the Diffie-Hellman exchange by itself does not provide authentication of the parties, and is thus vulnerable to man in the middle attack. The man-in-the-middle may establish two distinct Diffie-Hellman keys, one with Alice and the other with Bob, and then try to masquerade as Alice to Bob and/or vice-versa, perhaps by decrypting and re-encrypting messages passed between them. Some method to authenticate these parties to each other is generally needed. A variety of cryptographic authentication solutions incorporate a Diffie-Hellman exchange. When Alice and Bob have a public key infrastructure, they may digitally sign the agreed key, or ga and gb, as in MQV, STS and the IKE component of the IPsec protocol suite for securing Internet Protocol communications. When Alice and Bob share a password, they may use a password-authenticated key agreement form of Diffie-Hellman.