I wish to demonstrate asymmetric encryption using real-world locks. For example, I want to write a secret on a piece of paper and deposit it in a locked box. Is there a lock I can buy that comes with two keys, one that only locks the lock and another that only unlocks the lock?
The usual example is a padlock and a key for it.
Bob gives Alice a padlock (his "public key") and he keeps the key for that padlock (his "private key").
Alice puts a message in a box, and snaps the padlock on to it. She then sends the box to Bob.
Bob can unlock it with his key.
An extended version of this is described at https://web.archive.org/web/20130708131404/http://www.economicexpert.com/a/Asymmetric:key:algorithm.html
I like David's answer, but just thought I'd mention that I've seen that demonstrated as a bad example of security - the reasoning was that there was no way to ensure that Alice received the padlock that Bob sent (Eve could swap it for a different padlock in transit)
The demonstration then moved on to an example with one box and two padlocks, which was demonstratively secure...
Alice puts message inside the box and locks it with her padlock (public key padlock)
Sends box to recipient (Bob)
Bob adds another padlock (private key padlock)
Sends box back to Alice
Alice removes the public key padlock (with her key), meaning the package is now protected only by the private key.
Alice returns box to Bob who can now unlock with the private key.
For added effect you can have an Eve passing the boxes back and forth and showing that at no point can Eve get into the box. Its a great physical example, and easily understandable to showing the package is secure at all points.
Use a box with two doors and two different locks. Arrange the internals of the box so it works one way, similar to a street corner mailbox.
Alternatively, view the box plus padlock combination as the encryption key. You construct a message by getting 1) a box, 2) padlock, 3) putting something in the box and locking it. The physical key for that padlock is then the decryption key, which fits the model since the encryptoin key can't unlock the message.
The magical lock should have two keys (let's assume they are key1 and key2).
If you lock it with key1 then you can not unlock it with key1.
If you lock it with key2 then you can not unlock it with key2.
If you lock it with key1 then you have to unlock it with key2.
If you lock it with key2 then you have to unlock it with key1.
So, if i lock with key1, then the other person will lock with key2. Then he can lock it with key2, and i will be able to open it with key1.
Let's take one step further. Let us make 1000 copy of key2 and distribute it publicly. Now anyone can take key2 (including thieves and cheats) and lock the box and only me with key1 can open it. This will give us confidentiality.
Now, if i lock a message with key1 then 1000 (including thieves and cheats) people can open it with key2. So, confidentiality goes out the window. Then why would anyone want to do that? Well, it gives us authenticity. I mean, If you were able to open the box with key2, then the message inside was definitely by me as only I have key1.
In encryption world we call key1 private key and key2 public key.
The keys are mathematically linked to each other. To be a little more precise, both keys are created with a equation which has lots of solutions. You can only unlock if you can get the solution. Now, key1 has enough hints to get the solution of key2, and key2 has enough hints to get the solution of key1.
That is Asymmetric Encryption in a nutshell.
If you want to take it a step further, check out CoreStreet's smart card lock products. This is their business.
Related
I have a fundamental confusion about the public key cryptography in the Bitcoin (Blockchain) field.
For example, I understand that, in Bitcoin, when Bob wants to make a transaction, he sends out a transaction that contains the following:
The plain transaction message (such as Bob sends 5 Bitcoins to Alice).
Bob's public key
The digital signature of the transaction, signed using Bob's private key
I understand the whole Bitcoin network will validate this transaction based on Bob's public key and digital signature, which is broadcasted along with the plain transaction info all across the network.
However, what if the above transaction (that Bob sends Alice 5 bitcoins) is initiated by Eve? Eve broadcasts the plain transaction message, her public key, the digital signature signed using her private key. It seems the whole Bitcoin network will also validate the transaction based on the provided information.
Can you please clarify what type of wrong thinking I'm having?
Thanks a lot!
Cheers,
M.
Everything is correct. But, Bob cannot send any Public Key. He must provide the Pubkey, related to the address, from which he take 5 BTC for send further. In the Bitcon design, the address is hash of the Pubkey.
As result, Eve does not know pubkey for Bob's address, and she unable send transaction, which spends Bob's money. But, of course, she able to send transaction with pubkey for address, she owns. By other words, Eve can spend her own money, and this is OK.
If you will see details of the Bitcoin script, you will see typical spending script:
ScriptPubKey = OP_DUP OP_HASH160 OP_EQUAL OP_CHECKSIG
This script duplicate pubkey, hashing one copy, compare hashed copy with btc_address, and if equal - checks signature. As you see, no any pubkey acceptable.
I'm working on a distributed application, and we need a way to authorize clients. Every client has a PGP keypair associated with them, and we require them to enter their private key (which is not stored) through which their pubkey is derived and used to identify clients and modify their fields on the distributed database.
Now, considering user experience, entering a private key on a website whenever you need to do something is troublesome. But we also cannot maintain a central database for username/password based authentication as that creates a single failure point (not what the distributed application is meant to do)
I am hoping there is some way to get an easier to remember human readable descriptor of the private key which can be used to authenticate if something like that exists. Any other ideas are appreciated too.
I'll throw a bunch of ideas to clarify the question:
Are you certain that PGP is suited for your needs?
I feel like you should provide some more details to be sure:
- How are the private and public keys used exactly? I understand the following : user inputs its private key, information is decrypted and modified, public key is deduced from private and used to encrypt the updated information.
- How is this different from using a regular password and being able to authenticate the user and encrypt data?
- You seems to send private keys on the network, and they should remain private.
How you could use a regular password:
User has a password, your application uses a function (e.g sha256, KDF,...) to make it usable by classical encryption algorithms (e.g AES). With the same (not stored) key, you can then encrypt and decrypt datas. You just have to make sure that decryption is valid, by adding a known value at the beginning of the data (e.g a part of the key).
Quick example:
password: "WeakPassword"
key: sha256("WeakPassword"+"MySalt") = 493e3ae...b2eec8ef
Decrypt(data,key)
clearData = "493e3ae{123;456}" //valid, because you can check the beginning
Encrypt(clearData,key)
Advantages: usable passwords, faster symmetric encryption
Use a QR code
If you stick to PGP and have a camera available it is pretty handy.
You could also use hexadecimal, base64, ... but for a 2048 bits RSA key, that still gets you hundreds of characters.
I tried google, but its not what I want. Google says, its a gathering to check how securely a signing key is stored based on distributed access to the key.
I have this class which has 3 Strings(broken key) and respective attributes (key check values, zone key check values, encryption master key). Using which I derive a Master key. I cannot put up the code here, as it violates my security policy. btw this is for smart cards.
If any one has any idea of this, please explain or point me to it.
OK, I'm going to be assuming a simple symmetric key (3DES or AES) split into 3 parts here. I can only answer because I make this assumption.
A key value is randomly generated, this is the key you're going to protect. Lets call this key the master key. A KCV (key check value) is calculated over the master key, so if it is regenerated the correctness of the key can be verified with relatively high certainty without revealing the value itself. The KCV doesn't leak information about the key material itself as the calculation of the KCV is one way.
This key is split into three parts using other random values and XOR. First two other random keys are generated. The third key is calculated to be the XOR of the other keys and the master key. KCV values are calculated and written down. The three keys can now be distributed to 3 different actors. These actors are called key managers in the role they perform in the ceremony. Commonly the key managers secure access to their key.
Now to regenerate the master key each key manager writes down their part of the key. The KCV of the key is verified before proceeding to make sure that no input errors have been mode, or that the value is not that of a different key. Now if you calculate the XOR of the three keys then you'll get the master key again. This value is again compared to the master key.
So that's all there is to it.
With regards to the security of this scheme:
you need all three keys as the other keys basically provide a One-Time-Pad encryption over the key value, which provides a very strong notion of security
the common KCV is a dangerous notion, as an encryption of an all zero block - the most common scheme - may leak sensitive information (e.g. for counter mode security with a zero nonce and counter). E.g. a HMAC over an empty value may be a better idea
obviously you need a secure random number generator to generate the keys or your scheme is likely to be insecure
it will be hard to generate the wrong key on purpose; commonly the KCV is three bytes, so the chance of one or two people colluding and generate the KCV of the master key is 1 in 2^24 (2^24 is over 16 million).
Key Ceremony in cryptography means that how you will activate your Signing key for different purpose like CA key when issuing a certificate. Key Ceremony have very strong security level that a key is activate with m of n rule, key is stored on secure physical location in Laptops or in HSM(hardware to store keys).
For more detail see WebTrust Principles and Criteria for Certification Authorities – v2.2 document ,download from http://www.webtrust.org/principles-and-criteria/docs/item83987.pdf, in section 4.4 CA Key Usage
On a high level, It's a process of rotating the cryptography keys on Production/UAT environment between two entities and then one entity send a request to another entity to make a session between them with the help of the keys. Keys can have certain roles to encrypt/decrypt the message, to check the integrity of the message e.t.c.
I'm just wondering if I should encrypt user contact information when I store it in the database?
E.g. emails, phone numbers etc...
Normally you only encrypt sensitive information, and this depends on your project requirements. If the user email or phone number is sensitive, encrypt it. On the other hand, as you will need to get the contact information from database, you will use symetric encryption, and it is easy to desencrypt, so your "security" in this case is only ofuscating data and is not strong enough.
Anyway, you should always encrypt the sensitive data such as password, and I suggest assymetric encryption with hash.
In my projects I never needed to encrypt any contact information, and only passwords are encrypted on the database. If you are implementing web application, I suggest you to use security tokens (claim based security) and make all contact information to be encrypted while travel on the net (by using message or transport security) so there are very low risk to disclose any contact information to the third party.
I'm going to address the broader question: Should I encrypt?
In my VERY humble opinion, if the information is in any way associated with a person's identity and there is public access to your site or network, the answer is a resounding YES. I'll ignore the technical complexities of indexing and searching encrypted information and just give you the following to think about:
Identity and credit-card thieves and are not likely to get all your information from one source.
Information they are likely to pursue in pieces are broad. Name,
address, phone, CC number and expiration date, etc...
Once a person possesses fragmented records, all that information can
be used in an attempt to associated one fragmented record with
another. IE, John Smith in Garland, TX is likely to be J Smith at
1111 Some Dr, Garland, TX.
Once successfully associated, fragmented records from YOUR data
combined with fragmented records from MY data become a complete
record, then OUR customer's life is a wreck.
This is a very simplified path, and lots of information is public record so in one sense protecting it is a moot point. However, if you are slapped with a lawsuit, and it DOES happen, that may be of little comfort when you're coughing up $500 a hour to your attorney.
Encrypting contact information only makes sense if you expect your security to be compromised or know that untrustworthy people will have direct access to your database.
One-way encryption (hashing) will render your data useless since there is no way to retrieve it so you'll have to use some form of reversible encryption.
Encrypting contact info in your database will have a couple of downsides, most notably:
Encryption is not free, it takes time to process the data
You cannot search the encrypted data based on partial data like a partial contact name
Note that the weakness of reversible encryption lies with the key required for decryption. Don't store that in the same database.
Using transport layer security (like SSL) makes more sense.
Alice wants to know from Bob the location of a sensitive resource. Bob Kindly tells Alice the location, but how can Alice be sure of the identity of Bob?
Bob is a OpenBSD server, and the source of data is a Python/C++ App.
My Idea was:
Alice Knows Bob's public Key.
Alice encrypt a random string with Bob's Public Key, and send it to Bob.
Bob recover the random string, and hash it. Bob send back the sensitive resource, along with the hash.
The problem of this method is: Can I safely store a private key on Bob (the server)? How? Is there a better solution?
If Bob doesn't have a private key, then what else does Bob uniquely know that it can use to identify itself? And if you can't trust Bob to keep its private key safe, you're sunk no matter what you do.
If it's worthwhile spending the extra money, one thing you could do is have another machine (call it Cipherclerk) that is not online, can communicate only with Bob, and will only make certain kinds of communications. Cipherclerk holds the private key, and uses it to decrypt things for Bob. Then, even if Bob is compromised remotely, at least the private key isn't compromised with it.
An enhancement to your idea would be to have Bob use Alice's random string as a symmetric key to encrypt the resource.
This method is completely insecure if someone can mount a man in the middle attack. Mallory, the attack, can simply strip the the sensitive information out, substitute it with hers, and forward it on to Alice.
The solution is to use TLS or SSH. In either case, make sure Alice has bob's public key or key fingerprint. This is a widely used solution and is secure assuming no one can change the data Alice stores or read the data bob stores.