Uploading private keys puts users at risk

[englishm]

Just looked at the usage message for keybase push:

keybase push -h
usage: keybase push [-h] [-g] [-p] [-s] [search]

Positional arguments:
  search                search parameter to find the right key

Optional arguments:
  -h, --help            Show this help message and exit.
  -g, --gen             generate a new key
  -p, --show-public-only-keys
                        Allow picking of public keys for which no secret key
                        is available (not recommended)
  -s, --secret          push the secret key to the server

"push secret key to the server" is not something that should ever be encouraged. It puts users at great risk.

[lyndsysimon]

:+1:

In what circumstance would pushing a secret key to the server be desirable?

[ghost]

It is my understanding that private keys are not uploaded in plaintext, but encrypted with the user's passphrase. This allows the browser to download the private key, unlock it on the client side with the passphrase, and thereby allow keybase to function. Perhaps a keybase dev can clarify.

[malgorithms]

Hi guys - this is a feature we'll continue to support. Many of you early users - who are of course skewing to the more security conscious - will not use it.

There are a few reasons one might wish to do this. All of them center around easy transportability of their secret key. For example, I'd like my secret key on multiple machines, and I don't know how to move it around easily. If I'm the average computer user out there, almost all solutions are strictly worse than what we're doing with keybase push -s

We'd like as much review as possible of our process for pushing and pulling secret keys from the server. Your key is triplesec encrypted (https://keybase.io/triplesec) client side, and you could do this yourself with triplesec if you don't trust the client to do it.

It's not there as a mistake, but we know that many people who use the command line version will not use it.

[michiexile]

You don't actually have to remove it to discourage it; and I agree with several other earlier comments that this is something you should strongly discourage for a wide variety of security reasons - including what happens if you lose your database.

I'd suggest something like have the actual process of pushing a secret key include several steps of information about what ramifications the decision would have and what feasible alternative methods could work. This way a user who chooses to do this will do so well informed, rather than almost completely uninformed.

We who react now are all people who wouldn't touch the functionality with a 10' stick. But the question isn't really about us: what worries us is (inter alia) the lack of user education coming with the option, as well as the various levels of inherent risk in even offering the feature.

[zQueal]

Although I agree that it's totally insecure, no matter how you sugar coat it--I really don't think it's a feature that should be removed. One of the major points to keybase as a product, at least to me, is to bring PGP keys and authentication to the layman. Not everyone is able to use the command line, so having a secondary option just makes sense.

As an example, Facebook and 2Factor authentication. It just makes so much sense to enable it, considering our phones are always within hands reach from us, but ask yourself how many do you think actually have it enabled? If your facebook account gets taken over, it can really hurt your social image in the same ways as your private key getting taken.

Just some food for thought.

[MattSurabian]

It's a feature I'll never use, but probably a good time to point out that this is why one's private key should be protected with a strong and secret pass phrase. The PGP protocol is structured such that possession of the private key alone is not sufficient to encrypt, sign, or decrypt without the passphrase.

It still strikes me as a terrible idea, but provided a proper host-proof storage solution is implemented by Keybase it's not Armageddon.

:+1: to clearer messaging regarding the the potential risks. The general idea of keybase is crypto that's more available to the masses, and at least a small piece of that should be best practices education. It's conceivable that a user coming to PGP for the first time might make the mistake of using a short, or otherwise poor pass phrase while also choosing to upload their private key to the server simply because they aren't aware of the pass phrase's intended function within the PGP protocol.

[orblivion]

For full disclosure, I'm not a PGP veteran by any means, but this strikes me as a fundamentally bad idea because the private key has been secured over many years of fixed mistakes. Maybe file permissions weren't ideal, maybe the random number generator wasn't great at this or that part of the process. It's the one really important piece of information that is critical to making PGP worth what it's worth. That it's now trusted with this new triplesec encryption, well, perhaps the developers are among the best, but it still hasn't stood the test of time. So you're taking a step back for integrity.

So you want to sacrifice some of what PGP has to offer in order to make it convenient enough for people to actually use. But you're going to dilute PGP in the process (assuming you're successful) by introducing a lot of people who have weaker standards (and people don't follow protocol that tightly as it is. and maybe that's a point in your favor). PGP and tools like it have the unique ability to withstand any storm that happens between your computer and the other party's computer. No matter what gets compromised in between you two, so long as your computer is safe (and I'm not saying it always is), your communication is safe. Your scheme doesn't fundamentally break this since the key is encrypted, but subjecting it to a new scheme makes this guarantee arguably a lot weaker.

Even if PGP is not practically a very secure system because of its awful user interface leading to people not treating it carefully, it's a model for a great system. It would just be a shame to break the model. There is a place for a less secure, but more widely used, system like yours (until somebody finds a way to make another robust system actually usable), why not start from the ground up? It's not like PGP is widely used among the people you're targeting anyway.

[kevashcraft]

I came upon this thread because the default option during the "keybase gen" function is to upload the private key and I was surprised. After reading the comments, I agree that the function is useful but I do not think it should be the default during the initial key generation.

[bdrewery]

This is a really bad idea. Whatever you claim on your intentions and security and as many reviews as you ask for, you are inviting hackers and skepticism. Encryption is hard. The world can review triplesec and not find any issue for years.

These things usually break down in other ways. A hacker, or a rogue employee, or a simple breakdown in your site's SSL, or rogue CA, could slip in code into the client-side encryption javascript to send the password somewhere and go unnoticed for minutes, hours, days, months. Any period of time would be unacceptable. This someone could then keep these keys for years until they find the right opportunity, and you'll never know. Just look at the recent Target POS fiasco. You are not immune to being hacked and manipulated.

Without client-side SSL cert pinning there is also great risk as well.

Yes, you have the feature with the intention of extending it to more people who would otherwise not have access to it, but you are also risking ruining the whole idea of it by storing private keys. "I can't copy my file around securely" is not a good reason either.

[bdrewery]

http://heartbleed.com goes to show just how bad of an idea this is. More things like this will happen.

Take it from the expert: "Unbreakable" Encryption Almost Certainly Isn't

[alexflanagan]

I agree with the usability reasons for having this feature, I'm using it to transport keys between work and home, and I think uploading the private key shouldn't be the default on keygen for the reasons above.

As a general software design principle I favour secure defaults. This default favours usability. It's an interesting tradeoff in terms of the command line client: the user there is probably more technical and so less concerned about usable defaults.

Loving the product though.

[plutext]

Compare https://blog.filippo.io/on-keybase-dot-io-and-encrypted-private-key-sharing/

[DanielHeath]

filippo claims that decrypting the (password-protected) key is arguably as hard as reverse engineering the private key from the public one.

That is absolutely, categorically not how crypto works and he should know better.

Assuming correct implementations and appropriate key sizes, reversing passphrase protection costs thousands of dollars in compute time; reversing the private key from the public key (without significant mathematical breakthroughs) is not achievable by all the computers on earth.

[orblivion]

I just wanted to note something I discovered, that may be of interest to others here who are troubled by the existence of this feature:

• https://keybase.io/dd9jn
• https://gnupg.org/.well-known/keybase.txt

Until this point, I've refused to use Keybase. However, though I don't get it, Werner Koch is okay enough with it to use it. It doesn't make sense to me to refuse to use it anymore if the guy who makes GPG doesn't protest.

[cwh1te]

Not providing an obvious means of uploading a public key is bad. Asking users to upload their private keys is worse. Storing those private keys unencrypted without the user knowing is just unforgivable (#2863). Shame on you, keybase devs. You should absolutely know better.

[smscotten]

This seems like a good use case for signed subkeys with the master key kept somewhere airgapped. Generate a brand new key pair just for use with keybase, not your master key, and not the key you use for daily email etc, but one that is still in your main keychain as trusted. And revocable at any time.

I still find it outrageous, but it is a way to make use of the feature without blind faith in keybase's good intentions.

[hadees]

What about supporting something like TREZOR? It seem like to me if you want to encourage laymen to use good practice a hardware key seems like an easy way to transfer. It could even be used like @smscotten suggests and generate a separate key that gets upload to your server which is just used for things that absolutely require a private key and/or you let users use the less secure key but checkoff on the risks.

[blob42]

@hadees Agree with you, for me a company that is advertising being all about security and ignoring and issue like https://github.com/keybase/client/issues/4675 and just waiting for public contributions says a lot about their priorities ...

After some years I decided to give it a try, I installed on my machine and when came the moment to send my public key I discover to my surprise Keybase needs the secret key. Sorry but I chose a Trezor exactly so the private key never touches an online machine and you not having support for hardware keys is a no go for me. Too bad the product looks really good but this is just security theater as far as I'm concerned.

[w2ak]

Hello !

While it seems to be now impossible to host a private key on keybase (keybase push tells to use keybase pgp select which promises not to upload the secret key whatever we do), certain webpages like the decryption page still advertise the possibility to host our private key on keybase.

Is this an incoherence ? If we cannot upload secret keys on keybase anymore, how is it that there are still a signing and decryption page on the web application ?

Thank you, neze

[aditsachde]

@w2ak It is still possible.

The reason I do use this feature is that I don't (and most others) use pgp often and across due to the complexity. I only use pgp on my linux machine (and really, its the only one I trust), but in the case that I ever need urgent access, I am able to use keybase to do it.

As with all good security practices, I keep up to date with keybase so if under any circumstances, the encrypted version is leaked, I can revoke it and if the attacker actually managed to decrypt it, they would find themselves revoked key.

[w2ak]

Thank you :smile:

I looked a little further and found the functionality. It seems a little hidden but all right.

@DenseComet were you able (did you try, by any chance ?) to upload only your private subkeys ? I did not try yet but if I were to upload my key, I would really want to upload only the subkeys.

Thanks !

[aditsachde]

@w2ak I generated keys and stuff on an offline copy of tails and only transferred the subkeys to my main laptop (so if I loose my laptop or keybase looses their database, its not as big of a deal). I had reset my account, then used gpg to export from my laptop and uploaded only those keys to keybase, which are the subkeys only.

[eduncan911]

I too follow the practices @DenseComet does. Though I don't use Tails (Tails erases everything on shutdown?), I do use an air-gapped machine for my master and secrets, issuing only sub-keys for my primary laptop, desktop and work machines. I never store nor use my master on any machine I normally use on a daily driver.

The only reason someone would want to go to this extreme would be to build solid faith in the documents (and messages) they sign as truly being them - as it's more difficult to lose your master key being stored offline.

It sounds like @DenseComet and myself do go to this extreme to prove our identities.

I've recently been asked by a security-group of individuals to join up on Keybase and every time I dig into it, it always wants my private key. I just cannot fathom why any application would want that.

Yes, the CLI may prompt for my phasephrase to sign my pubkey, to prove it's me.

Yes, the CLI has the option for pushing set to False by default - we think.

Yes, it is open sourced and I've been some time this morning crawling through the code to see if it is indeed set to false by default - and have ran out of time looking for that code.

Even if I was able to find that piece of open source code, what's to guarantee that the downloaded application on macOS or Linux CLI doesn't have a different flag set? Sure, it's signed by the publisher - but still I'd be more comfortable tweaking the source to basically break the push of my key and compiling it myself. Oh which I spent an hour trying to get ramped up on this morning, and just ran out of time.

So to all of those hesitant, here's what I am doing... This laptop is somewhat trusted by me. I only use a sub-key with a short expiration on this machine, with no master secret. I will use this to sign my keybase account, knowing that I can revoke it in the public domain at a later time if my machine is compromised. They say they won't upload... And I am willing to risk it considering the small timelines I use with my sub keys to expire them.

[syang]

echo what @michiexile said above, would a high level architecture diagram help educating the mass? Unlike GPG keyserver, keybase server is a proprietary implementation, and I think it may be understandable for whatever commercial reasons; but at least an educational diagram from user risk awareness and assurance perspective would help.

BTW, I got directed here through this discussion: https://superuser.com/questions/227991/where-to-upload-pgp-public-key-are-keyservers-still-surviving

[wiktor-k]

@syang I doubt that would ever happen. From my perspective Keybase is interested in making encryption easier to use even when it contradicts best practices (e.g. offline master key) because they're more interested in a broader audience rather than the "long tail" of "specialized" users. That would also explain why they don't provide standard keyserver API (HKP) and are not interested in the general OpenPGP ecosystem.

[aegershman]

Can confirm: I'm a huge idiot who knows nothing about encryption && I'm perfectly happy uploading my private keys into Keybase, at least for the time being until I get better at understanding encryption. Until then, I'm more than happy to take a risk if it means the barrier to entry is lower.

[blob42]

@aegershman if you trust your private key with a private proprietary third party it is indeed lowering the barrier to entry for "security theater". If Keybase is honest about their aim to make key management more user friendly they should at least post an update on this topic and their motive for not taking it seriously. Hardware based keys are getting more widespread and they are incompatible with the current keybase CLI.

[eduncan911]

So I am coming back to say that Keybase doesn't use your PGP key.

As mentioned in my previous post above:

• I use subkeys generated offine using my master key with short expiration dates.
• I did not push my key to keybase when using the CLI to import it.
• I cannot use the web GUI, because I did not oush my key (which is fine, and I prefer it that way)
• My subkey has expired 4 months ago, the one I gave to keybase.

However, I'm still able to send/receive messages, and encrypt and decrypt old and new files on the KBFS - with a long expired subkey.

Now that begs the question... Why does Keybase demand my private key over and over when setting it up without keygen, if it isn't even used?

The only thing I can think of is to prove my identity it posts in my profile. But in that case, why even have an "upload" feature as it's not even used?

[zQueal]

@eduncan911 if this is the way you intend to use Keybase, a better question to ask yourself would be "why use Keybase at all?"

It doesn't seem to be the type of software you're comfortable with using. So why?

[ghost]

@DanielHeath @malgorithms @aegershman @eduncan911 I have a doubt. decrypting an encrypted form of private key is same as decrypting an encrypted data; correct? Neither the former nor latter is feasible without passphrase; correct?. If it is feasible, then it is the issue cryptography itself and not with uploading encrypted form of private key?

[eduncan911]

@zQueal the question was asked:

Why does Keybase demand my private key over and over when setting it up without keygen, if it isn't even used?

If it is to just prove your identity, then why have an "upload" feature at all?

I've had long discussions on the keybase public channels and there is no clear answers to these.

I originally assumed that keybase was encrypting all of my traffic to other users using my own pgp key. This would make sense to offer an upload feature of the private key.

But it is now clear that is no where near the case at all, so why even allow it an upload feature? It doesn't make any sense, even for "making pgp easier" which was one of the original reasons keybase was created.

It may have indeed been an old concept to use your own pgp key. But no longer is that the case.

[zQueal]

If it is to just prove your identity, then why have an "upload" feature at all?

Because presumably only the owner of the key would have the private key....

I've had long discussions on the keybase public channels and there is no clear answers to these.

There are several, in addition to the one I just posted.... Keybase is a "wrapper" software which enhances GPG and by extension PGP--many people find a web interface to encrypt data to a specific person advantageous which is impossible to do without the use of their private key. In addition to that, it makes the chat feature work by encrypting part of the conversation with your own private key--so you don't have to trust that keybase is using a strong key. You know they are, because its your own key.

Don't want to do that? Then don't upload your private key at all. It's entirely optional and only reduces Keybases' usability in areas that require your private key.

So I ask you again, if you're not comfortable with uploading your private key, then why are you using Keybase? A the end of the day it makes working with PGP easier, it is not the only way to use PGP. Simply stick to using GPG....

I'll never understand how the slew of anti-upload-your-key comments in this thread are still continuing. If you're not comfortable doing it, then simply don't use the software--they're not going to change the usability and ease-of-use of Keybase to make a niche comfortable in using their software.

[mariuskiessling]

@zQueal I think you are missing the point of the argument when saying this:

I'll never understand how the slew of anti-upload-your-key comments in this thread are still continuing. If you're not comfortable doing it, then simply don't use the software--they're not going to change the usability and ease-of-use of Keybase to make a niche comfortable in using their software.

As you say, you provide a wrapper for the PGP functions that provides the same functionality in a more comfortable way. As pointed out by many users before me, the upload of private key is inherently insecure. No matter how much easier it makes it for users to use keybase, you endanger all those who do not have a deep cryptographic understanding. Don't get me wrong; I absolutely love the ease of the chat and encrypted file system. Though when building a secure key exchange solution that also targets non-technical users, don't include such a feature (at least without a very, very clear warning). simply don't use the software is not a valid argument.

[eduncan911]

@mariuskiessling a bit of a tweak to your comment, and contrary to @zQueal 's comment, your own private PGP privatekey is not used by Keybase. Period.

That's the core issue. It may have allowed you to own your own keys in the past; however, that is not the case any longer. They changed the communication protocols a while back to their own internal keys. Now, your own privatekey seems to only be used to sign/prove/add your own pubkey such as mine at https://keybase.io/eduncan911.

Your own privatekey is not used to encrypt files nor for chats at all. I've proved this with my comments above, specifically around my sub-key that expired last July 2018 - and I am still able to fully utilize Keybase today with all previous and new encrypted files as well as chats. I have yet to add another sub-key. As a matter of fact, I haven't formatted that laptop yet just out of pure spite to see how long keybase continues to work with an expired sub-key - now over 1 year expired.

So if your own private key is not used, then why demand it when adding your PGP pubkey? You could easily auto-sign a message from keybase via CLI, for "ease of use" during the proof of stake - without asking for your privatekey.

And the better question, why even ask for it to be uploaded - if it's not even used anywhere, on any other machine nor any other device?!?

What people are missing is that you no longer own your PGP keys with keybase - they generate their own internal keys and sync it to your devices as you "trust" those devices (and all internal NSA-spying that comes along with those assumptions, for the paranoid among us).

IMO, the best way forward is to just to remove the PGP portions from the CLI and be done with it. Or, to modify it to remove any need for a privatekey - and just ask the user to sign a message, to prove their pubkey is theirs (if that's only what it is being used for).

[zQueal]

There seems to be a ridiculous misunderstanding here. I do not work for Keybase. I do not represent Keybase. I am not affiliated with Keybase in any way other than I was here in alpha and have been watching the project for a long time. I've been added to a group which watches Keybase changes, which is why it says Member next to my name. For no other reason.

your own private PGP privatekey is not used by Keybase. Period.

I can literally create an encrypted message to myself using the Keybase interface and decrypt it using GPG on my PC which does not have Keybase installed. That would be impossible if Keybase didn't use my Key. So you can scream this until your head explodes but it's empirically untrue...

I don't think you seem to understand that there's a difference between the Keybase application encryption which uses saltpack and the Keybase GPG wrapper which uses PGP. They're not one in the same.

keybase decrypt

is not the same as

keybase pgp decrypt

One decrypts using Keybase saltpack, the other uses your key. To say that your key isn't used by Keybase is not only fallacious, but it's just plain ignorant man. Certain features of Keybase require saltpack and cannot be used with normal PGP. Signed and encrypted git repositories is one example;

Each device you have added to your account has a saltpack encryption key. When you create a new encrypted git repository that device signs it, and encrypts it. It's not using your PGP key because that application of PGP is impractical, however, you still need to use the password that protects your PGP key to unlock your keyring, so only the owner of the private key, and the person who knows the private password will be able to do these things.

Please read the help manual;

"keybase encrypt" provides strong integrity guarantees. By default, messages are signed with the key of the encrypting device.

...

"keybase pgp encrypt" requires an imported PGP private key, and accesses the local Keybase keyring when producing the signature.

The entire basis of your argument is based on your own misunderstanding of how Keybase works as a whole.

[eduncan911]

To clarify, none of us here are talking about the PGP wrapper of keybase pgp decrypt. Assuming this is what this conversation has been about may have been your mis-understanding as well to own up to as frankly it's the first time it is mentioned.

We've, or at least I, have stated multiple times that I can send chats to groups and friends, and encrypt/decrypt file using the Keybase filesystem - which all the docs said defaults to the key on my machine, which is just false. You said it best:

"keybase encrypt" provides strong integrity guarantees. By default, messages are signed with the key of the encrypting device.

I carefully and purposely used a clean machine, imported a limited timed sub-key pair as my private key, installed keybase and set up my account from that machine. This seemed to be the cleanest way possible.

This also seems to be the way keybase pushes its users to doing, assuming they are using their own keys. But I have shown this isn't so, or at least not very well documented or called out as not using your keys - when you forced to add your key.

If keybase uses your key of the machine by default, then answer me this:

How come keybase continues to work with my 1-year expired sub-key - the only private key this machine has had, and the original machine I setup keybase on? How come all chats and files I used originally are all still accessible - once my keys have expired.

Documentation does not reflect code. You can spit out all the docs you want, but the fact is keybase has continued to work with an expired keypair on my device for over a year.

Maybe you can link us to direct code blocks that prove me wrong. Because as end users, we are seeing other functionality.

And to call someone derogatory names because you do not understand the use cases of the end user is uncalled for.

[zQueal]

We've, or at least I, have stated multiple times that I can send chats to groups and friends, and encrypt/decrypt file using the Keybase filesystem - which all the docs said defaults to the key on my machine

Yes, your machine key which is saltpack and not PGP. That's what the entirety of my last post was about which has me wondering if it was read at all. I even posted an image which does an excellent job of visualizing it.

How come keybase continues to work with my 1-year expired sub-key

For honestly the very last time, because the functions that you're doing are clearly using your saltpack key and not your PGP key. See the image above.

And to call someone derogatory names

I used ignorant because this is the very definition of it. I've tried to impart to you several times that the functions you're using are clearly using your machine's saltpack key, and you keep reiterating your empirically incorrect point over and over. I'm sorry if your feelings are hurt but that's ignorance by literal definition. If you feel the need to take that as an insult, then that's your prerogative.

My original points stands terra firma. If you don't want to upload your private key, then don't. Why you're acting like your arm is being twisted off, or that you're somehow being forced to do it is beyond my understanding here. Advocating for its removal is also incredibly perplexing. For all and every intense and purpose Keybase is a software which you simply don't and continually refuse to trust.

So don't use it and all of your problems are magically solved.

[cben]

Could anyone summarize the current situation? The help for keybase pgp gen no longer mentions pushing to server, only to local gpg keyring.
If I generate a key, will it get pushed?

There is a keybase pgp push-private command that pushes to KBFS, and pull-private.
Is this the same mechanism discussed above?
Apparently it's a separate mechanism, as I do have my private key in the keybase.io website, but pull-private with the fingerprint from the site failed? [Exporting from the site (under "edit" key) and doing gpg --import did work. But now gpg knows it but keybase pgp decrypt doesn't...]

[maxtaco]

Manpage for pgp gen says:

By default, the secret half of the PGP key is never exported off
of the local system, but users have a choice via terminal prompt
to select storage of their encrypted secret PGP key on the Keybase
servers.

There is a keybase pgp push-private command that pushes to KBFS, and pull-private. Is this the same mechanism discussed above?

No, it's different. The former encrypts with your password (so it can be accessed from the Website). That latter encrypts with your device keys, so it cannot be accessed from the Website.

[Exporting from the site (under "edit" key) and doing gpg --import did work. But now gpg knows it but keybase pgp decrypt doesn't...]

If your private key was available on the Website, I'm surprised keybase pgp decrypt couldn't find it. That could be a bug.

[cben]

[... But now gpg knows it but keybase pgp decrypt doesn't...]

Ah, my bad, I didn't notice a GUI dialog asking me to type the passphrase. Once I typed it, it worked.

[michaelfriedman]

one might wish to do this. All of them center around easy transportability of their secret key. For example, I'd like my secret key on multiple machines, and I don't

At the very least this should be highly discouraged rather than encouraged as it is currently. As far as I could see, there isn't even a warning. If Keybase is really about security and privacy, this shouldn't be a point of contention.

[maxtaco]

I'm going to lock this issue since the original concern has been resolved:

$ keybase push
Use `keybase pgp select` instead.

And then, to continue to quote the docs:

$ keybase pgp select --help
NAME:
   keybase pgp select - Select a key from GnuPG as your own and register the public half with Keybase

USAGE:
   keybase pgp select [command options] [key query]

DESCRIPTION:
   "keybase pgp select" looks at the local GnuPG keychain for all
   available secret keys. It then makes those keys available for use with keybase.
   The steps involved are: (1a) sign a signature chain link with the selected PGP
   key and the existing device key; (1b) push this signature and the public PGP
   key to the server; and if "--import" flag is passed: (2a) copy the PGP secret half
   into your local Keybase keyring; and (2b) encrypt this secret key with Keybase's
   local key security mechanism.

   By default, Keybase suggests only one PGP public key, but if you want to,
   you can supply the "--multi" flag to override this restriction. If you
   want your secret key imported into the local Keybase keyring, then use
   the "--import" flag. Importing your secret key to Keybase keyring makes
   it possible to use Keybase PGP commands like "pgp decrypt" or "pgp sign".

   If you don't want to publish signature chain link to Keybase servers, use
   "--no-publish" flag. It's only valid when both "--no-publish" and "--import"
   flags are used.

   This operation will never push your secret key, encrypted or otherwise,
   to the Keybase server.

OPTIONS:
   --multi  Allow multiple PGP keys.
   --import Import private key to the local Keybase keyring.
   --no-publish Only import to Keybase keyring, do not publish on user profile.

If there are concerns with the 2019 version of keybase (rather than the 2014 version), please reopen a new ticket with specifics.