Multiple private and public key for same user - database

If a user have 2 pairs of public and private key, how can the server that has the public keys know which one to use? The server should encrypt the message using the public key to that private key, however how does it know?

No. SSH does not do Encrypt&Decrypt, but Sign&Verify sequence.
The server sends some data, client signs them using its private key and server can verify the data using all of the public keys it has stored in authorized_keys file.
But in real world, there is optional phase before doing all the above. The client sends also the public keys to match correct public part on the server.

Related

Can I swap the private and public key within ZeroMQ

At the moment, I am investigating the possibilities to use ZeroMQ with Curve to secure traffic between my publishers and subscribers.
I have successfully implemented a pub sub system which is using CZMQ.
At the moment, my publisher is encrypting the data he wants to send with his private key and subscribers can decrypt this data using the public key of the publisher. This is more 'authenticating' data than 'encrypting' data. Because when there is a Man In The Middle he can still decrypt all the data because the public key of the publisher is public.
I'm coding in C with the latest version of ZeroMQ and CZMQ.
My publisher.c
zctx_t* zmq_context = zctx_new();
zauth_t* auth = zauth_new (zmq_context);
zauth_set_verbose (auth, true);
zauth_configure_curve (auth, "*", CURVE_ALLOW_ANY);
zcert_t* pub_cert = zcert_load("cert.key"); // private key of publisher
void* socket = zsocket_new(zmq_context, ZMQ_PUB);
zcert_apply(pub_cert, socket);
zsocket_set_curve_server(socket, true);
//start publishing from here
My subscriber.c
zctx_t* zmq_context = zctx_new();
zcert_t* sub_cert = zcert_new();
zcert_t* pub_cert = zcert_load("cert.pub"); // public key of publisher
char* pub_key = zcert_public_txt(pub_cert);
void* zmq_s = zsocket_new(zmq_context, ZMQ_SUB);
zcert_apply(sub_cert, zmq_s);
zsocket_set_curve_serverkey(zmq_s, pub_key);
//start subscribing to topics and receiving messages from here
From this point, the publisher is encrypting all the data with his private key and the subscribing is decrypting all the data with the public key of the publisher. I would like to swap this system.
So, I would like to encrypt all the data with the public key of the publisher and decrypt all the data with the private key of the publisher.
I have tested it and changed the zcert_load("cert.key") to zcert_load("cert.pub") in my publisher.c.
I also changed this code in my subscriber.c:
zcert_t* pub_cert = zcert_load("cert.pub"); // public key of publisher
char* pub_key = zcert_public_txt(pub_cert);
to this code:
zcert_t* pub_cert = zcert_load("cert.key"); // private key of publisher
char* pub_key = zcert_secret_txt(pub_cert);
When I run my publisher and subscriber with these code changes, the publisher is constantly giving me the message: CURVE I: cannot open client HELLO -- wrong server key?
My question: Is it possibile to use a public key for encrypting data (publisher socket) and the private key for decrypting data (subscriber socket) with the architecture of ZeroMQ and CZMQ ?
Many thanks in advance,
Roy
I think you're misunderstanding the ZeroMQ CURVE mechanism. There are two great articles written about it by Pieter Hintjens, one is theoretical, where you can find this:
Clients and servers have long-term permanent keys, and for each connection, they create and securely exchange short-term transient keys. Each key is a public/secret keypair, following the elliptic curve security model.
To start a secure connection the client needs the server permanent public key. It then generates a transient key pair and sends a HELLO command to the server that contains its short term public key. The HELLO command is worthless to an attacker; it doesn't identify the client.
The server, when it gets a HELLO, generates its own short term key pair (one connection uses four keys in total), and encodes this new private key in a "cookie", which it sends back to the client as a WELCOME command. It also sends its short term public key, encrypted so only the client can read it. It then discards this short term key pair.
At this stage, the server hasn't stored any state for the client. It has generated a keypair, sent that back to the client in a way only the client can read, and thrown it away.
The client comes back with an INITIATE command that provides the server with its cookie back, and the client permanent public key, encrypted as a "vouch" so only the server can read it. As far as the client is concerned, the server is now authenticated, so it can also send back metadata in the command.
The server reads the INITIATE and can now authenticate the client permanent public key. It also unpacks the cookie and gets its short term key pair for the connection. As far as the server is now concerned, the client is now authenticated, so the server can send its metadata safely. Both sides can then send messages and commands.
So the keys you generate here are not used directly to encrypt data, they are only used to authenticate parties. The handshake process between client and server produces real encryption (and authentication as in MAC) keys that are used to encrypt the data. So if the only concern you have is MITM, you're already protected.
But you can also be concerned about rogue clients, your current scheme allows anyone to connect. This is where the second article by Pieter Hintjens can help you with "The Ironhouse Pattern". The critical part is to disable CURVE_ALLOW_ANY and tell server where to look for client public certificates:
// Tell authenticator to use the certificate store in .curve
zauth_configure_curve (auth, "*", ".curve");
Then you generate client key on the client (once! not calling zcert_new() for every connection), transfer its public part to the ".curve" directory of your server and load (on the client) that key instead of calling zcert_new().
If you want to make life a bit easier (not needing to transfer public keys from client to server for each client), you can create a "golden" client key pair, get its public part into the ".curve" store and then (via a secure channel, of course) copy the secret key on every client that needs to connect to your publisher.

Verify private key pass phrase after extracting key from PKCS#12 file

I'm trying to read the PKCS#12 file and extract private key programmatically in C. I've found here solution, but this program automatically decrypts my private key and checks only the PKCS#12 file password. Is there any way to also verify the private key passphrase?

Sign with private key and verify with public

OpenSSL's rsautl allows signing with a private key. This is without a hash. Then recovering the signed file with a public key.
I've looked at CryptCreateHash/CryptSignHash/CryptHashData but I'm not sure how to do it. I believe those functions will only sign the hash of the data, not the data itself.
Is there any way I can sign with the private key and no hash involved?
Edit: Made necessary changes from jww's recommendations.

How to sign a SAML2 assertion with the encryption key(s)

I need to create a SAML2 assertion for a business partner we work with, who now requires a SAML2 SSO. We would be the identity provider.
They sent us their Public Key. We created a public key and sent ours to them. During the creation step, we had the option to exclude the private key and we did so.
I am not sure which combination of keys, and which form of the key (public or private), is used in the signing phase. What do we do with their public key? What do we do with our public and private keys? Do I have to create another version of our key that includes the private key?
Would someone care to offer a simple step by step explanation of a generic signing process, making clear which form of the key is used, and when?
First off. You do not give your private key to another entity. The whole point of the private-public key system is that you dont need to share you private key.
Signing is done with your private key and verified using your public key.
Encryption is down using theirs public key and is decrypted using their private key.

Session data not persisting in GAE (Java)

I am struggling while handling sessions in GAE. I am trying to store a two classes and a string in session. Although on DEV environment it runs fine, on production a class and a string are not being persisted in session. The class that is not getting saved as a session attribute is as follows:
#PersistenceCapable(detachable="true")
public class Agent implements Serializable{
#PrimaryKey
#Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
private Long id;
#Persistent private String name; //Name of the Agency
#Element(dependent = "true")
private List<Contact> contacts = new ArrayList<Contact>();
#Element(dependent = "true")
private List<Agency> agencies = new ArrayList<Agency>();
#Persistent private List<Long> subAgents = new ArrayList<Long>();
#Persistent private Date createdOn = new Date();
}
I would like to mention again that it works fine on DEV Environment but on production I get values as null. As you can see I have made the class implement Serializable. But I think it is not the problem because I am setting one more attribute as a simple string and that also is failing (I get the attribute value as null). Session however is created as I can see it at the backend and also there is one more class which is persisted in session.
Anybody have suggestions? Thanks in advance.
Your problem is probably related to either:
GAE often serializes sessions almost immediately, dev environment doesn't. So all objects in your graph must implement Serializable.
BUT EVEN MORE LIKELY is that after you modify a session variable, you must do something like req.getSession().setAttribute(myKey,myObj) - it WILL NOT see changes in your object and automatically write them back to the session... so the session attributes will have the value of whatever they had when they were last set.
Problem #2 above cost me countless time and pain until I tripped over (via a lengthy process of elimination).
Have you enabled sessions in your configuration file?
http://code.google.com/intl/en/appengine/docs/java/config/appconfig.html#Enabling_Sessions
Making classes Agency and Contact Serializable solves the problem. That mean each and every object (be it nested or otherwise) which is present inside a session attribute should be serializable.

Resources