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

Bouncy Castle meta information removal request #319

Closed
polterguy opened this issue Jul 23, 2017 · 26 comments
Closed

Bouncy Castle meta information removal request #319

polterguy opened this issue Jul 23, 2017 · 26 comments
Labels
enhancement New feature or request

Comments

@polterguy
Copy link

There's this principle in security that one should never give away information about the implementation used to secure a system, which brings me to the PGP message created by MimeKit, which includes not only the fact that Bouncy Castle was used to encrypt the message, but even its versioning number.

Would it be possible to remove this, and make the PGP encrypted messages completely anonymous?

PS!
The above reasoning is the reasons why among other things the HTTP standard explicitly encourages implementers to not give away versioning numbers of the software used to handle the HTTP request ...

@jstedfast jstedfast added the enhancement New feature or request label Jul 23, 2017
@jstedfast
Copy link
Owner

Yea, it's something I've pondered in the past as well. I'm pretty sure I saw a way to do this in the BC API, but just kept getting sidetracked :)

@polterguy
Copy link
Author

While we're at it, the default created MIME ID for messages also tends to "give away" some relatively private type of information. Example [email protected].

Not even sure if I could explicitly set it myself, as in if it's got a setter property - But especially for encrypted emails, the above is giving away a lot of information ...

Thx,

Can't wait to get my hands on your new stuff :D

.t

@jstedfast
Copy link
Owner

It looks like there's no way to avoid writing out a Version: header :(

ArmoredOutputStream.ResetHeaders() will clear all headers and then add back the Version: header.

The only thing I can think of is to disguise it as GnuPG or something?

@jstedfast
Copy link
Owner

jstedfast commented Jul 23, 2017

Ah, you can do: message.MessageId = MimeUtils.GenerateMessageId ("my-domain.com");

By default it uses your local hostname because that's the suggestion made by the specs.

@jstedfast
Copy link
Owner

Trying to figure out whether I should have an API for enumerating PgpPublicKeys or PgpPublicKeyRings. A key ring is a collection of keys owned by a single user, whereas a key is just a single key owned by that user.

@polterguy
Copy link
Author

Weird that you can't remove the PGP BC info. Do you know if this is mentioned as a criteria in OpenPGP or something? I'd suspect it would be considered a bad thing to do ...?

Regarding key rings versus keys, I wouldn't know. Normally I'd think people are looking for a specific key, and not a keyring ...?
At least that's what I am doing ...

About the MIME ID, am I too paranoid when I say I want to try to hide the local hostname? What alternatives could I use here, that still would be considered a "valid MIME ID" you think ...?

@jstedfast
Copy link
Owner

I don't think it matters that much since it's only the internal hostname of your machine, but I suppose it depends on what you name your machine (e.g. if you name it something sensitive, that might not be good).

I've added APIs to enumerate both keyrings and keys.

@polterguy
Copy link
Author

You're the champ! :)

@polterguy
Copy link
Author

Pst, ready to release, only awaiting your NuGet package ... :)

For the record, this stuff is built with your baby ... ;)

https://gaiasoul.com/2017/08/07/sephia-five-military-grade-cryptography/

@jstedfast
Copy link
Owner

Sorry about that. Just released 1.18.0 to nuget :)

@polterguy
Copy link
Author

Thx mate, did you read the link I sent you ...? :)

@jstedfast
Copy link
Owner

One thing that I've noticed that Outlook does is it'll warn you if the message you are reading was sent by someone you've never received email from before (or received very few emails from).

But an improvement on this feature might be to say "this email address looks similar to another email address in your address book, it may be a phishing email". I haven't really delved into fuzzy matching algorithms, but I think this would be one area that might be useful. Just figured I'd mention it since it seems to align with what Sephia 5 is all about.

One of the problems I have with GMail is that it seems to collect every address that I've ever had contact with into my addressbook, and so when I go to type an address, if [email protected] has sent me an email and I want to send an email to [email protected], it might autocomplete to johndooe instead of johndoe, exacerbating the "oops, sent it to the wrong person" catastrophe.

@polterguy
Copy link
Author

Interesting suggestions all of them. Your final point, I largely have a fix for, though not entirely. Yet still "good enough" I think, which is to create some better sorting when searching for contacts, according to volume, and/or last sent/received ...

@polterguy
Copy link
Author


/*
 * Opening connection, and performing the search.
 *
 * Notice, this query will select the 5 top contacts whom you have 
 * previously received emails from, starting out with the given query, 
 * in the name or email, in addition to that it will sort according to 
 * whom you last received an email from, and exclude contacts that have
 * been explicitly marked as spam senders.
 *
 * Which further will reduce the risk of sending an email to the wrong 
 * contact, since it is more likely that you would want to send an email 
 * to a person whom you have recently received an email from.
 *
 * Credits goes to my lawyer, and Jeffrey Steadfast, who proposed this 
 * little trick.
 */
p5.mysql.connect:[sephia]
  p5.mysql.select:@"select c.name, c.email from contacts c
inner join emails e on e.sender = c.id
inner join (select sender, MAX(date) maxDate from emails group by sender) e2 on e.sender = e2.sender and e.date = e2.maxDate
where (c.name like @query or c.email like @query) and (c.spam is null or c.spam = 0)
order by e.date desc
limit 5"
    @query:"{0}%"
      :x:/@get-widget-property/*/*?value

Basically, it will select the top five contacts, whom sent you an email, sorted according to who sent you an email most recently, excluding "spam" contacts, having the name or email starting out with whatever you type into the search query text box.

Pretty nifty if you ask me ...

Thx mate :)

.t

@jstedfast
Copy link
Owner

Cool! That would definitely be useful :)

@jstedfast
Copy link
Owner

What should we do about this? I'd like to get this resolved before making the 1.18.1 release if we can, but that probably means either giving up on it or else setting it to some other hard-coded value that disguises the real version details.

@polterguy
Copy link
Author

Hmm, I don't know. To be honest with you, I have seriously considered forking BC, optionally creating wrappers around it, using the original base as a foundation. There are other arguments in favour of doing such a thing too, such as that the code is not very intuitive, and highly "C# 1.0'ish".

Such an act (of arguably desperation), would solve it though.

Have you tried speaking to the devs of BC ...?

@jstedfast
Copy link
Owner

Hah, looks like Peter Dettman actually fixed it. Now I mostly just need him to make a new release...

@polterguy
Copy link
Author

Awesome!! Seems like I owe a lot of peeples out there some serious flowers!! :D

@jstedfast
Copy link
Owner

Potential bug in his fix: bcgit/bc-csharp@53a508e (mostly documenting this for myself so I can find my comment again, hah!)

I just did a bit of testing and it seems that even w/o a new release of bc-csharp, I can set the "Version" header to null and what we get is:

-----BEGIN PGP MESSAGE-----
Version: 

.......

So it kinda sorta already works, but there's just an empty Version: header in the armored output.

I think we can accept that for now until Peter releases a new nuget (at which point I'll update my nuget references and we'll get no Version: header at all).

jstedfast added a commit that referenced this issue Sep 3, 2017
@polterguy
Copy link
Author

Nifty!!
Still not entirely happy with the fact that it shows an empty "Version:" bugger, since arguably, it is "giving away information", that could be used to deduct which PGP lib is being used. But obviously it's better than having not only the "BC" parts, but even the freakin' version number of BC.

Besides, agree. Important to get it out, for then later to update when we've got the real goods.

@jstedfast
Copy link
Owner

Looks like Oren Novotny has made a release of BouncyCastle.Portable with the fix, so I'm updating MimeKit.Portable, MimeKit.WindowsUniversal81 and MimeKit.NetStandard to use that instead.

Not sure if you are using the .netstandard1.3 version of MimeKit or the old-school .net45 version.

@polterguy
Copy link
Author

Hmm, what's the different ...?

(I think I am using .net45)

@jstedfast
Copy link
Owner

.netstandard is the newer .NET Core stuff that Microsoft is pushing for use with ASP.NET

@polterguy
Copy link
Author

My stuff is built on WebForms, hence it probably wouldn't work, without a massive rewrite, which I don't see the point in.

"Microsoft keeps on pushing, and I keep on rejecting" ... ;)

@polterguy
Copy link
Author

Funny link ... :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants