Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Server authentication in transactions #186

Closed
wants to merge 12 commits into from

Conversation

bddap
Copy link
Contributor

@bddap bddap commented Jul 12, 2019

Adds a way to send grin to a server authenticated by its TLS public key. PKI is not required or used. The public key must already be known by the sender.

@bddap
Copy link
Contributor Author

bddap commented Jul 12, 2019

Blocked by #180

Ok(s) => s,
Err(e) => return Err(ParseError::ArgumentError(format!("{}", e))),
};
if cfg!(not(test)) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When using #[cfg(not(test))], tests were compiling and running successfully, but non-test builds were failing. This change makes sure type checks take place in both test mode and non-test mode.

@bddap
Copy link
Contributor Author

bddap commented Jul 12, 2019

I won't have time to finish this one, at least not in the near future. If someone else could pick up where I left off it would be much appreciated.

Some background:

These changes make use of the new trait, SlateSender, introduced in #180.

The the struct this pr introduces is called AuthenticatedHttpsSlateSender. AuthenticatedHttpsSlateSender is meant to implement SlateSender.

The implementation is complete except for the public key verification bit. I've left one rustc error behind to indicate the main unfinished part of this pr. Just run cargo check and you'll see what I mean.

Work so far is on the client (SlateSender). The server shouldn't require any code; just run the foreign api on https and note the public key used.

Once AuthenticatedHttpsSlateSender is implemented, authenticated sends can be added as a method to the wallet's send command.

Feel free to ask me questions.

@yeastplume
Copy link
Member

Going to leave this open for now as I think it's a good idea, but it's likely going to need discussion with the wallet subteam and possibly an RFC. I'm busy with other things at the moment, but if anyone wants to pick this up now help would be welcome.

@yeastplume
Copy link
Member

Going to close for now, as the focus is on TOR at the moment which handles the encryption without needing to provide extra keys to senders. If somebody's interested in looking at this further, please feel free to propose via RFC.

@yeastplume yeastplume closed this Oct 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants