
Show HN: Get encrypted data from people that don’t know how to encrypt - chomponthis
https://github.com/whitesmith/hawkpost
======
Tepix
A contact form that is hosted on a HTTPS protected website already does the
job. The main difference is that it is usually (but not necessarily) only
transmitted encrypted, not stored in encrypted form.

Here's a tip: If you generate an email from the content of the contact form
anyway, why not make it an encrypted mail? It's rather easy if you use mailx
from the heirloom-mailx package that is part of Debian, Ubuntu and probably a
lot of other Linux/BSD/UNIX distributions. Here are the required steps:

In ~/.mailrc:

    
    
       set smime-ca-dir=/home/user/smime
    
       set smime-ca-file=/home/user/smime/1_Intermediate.crt
    
       set smime-encrypt-user@example.com=/home/user/smime/2_user@example.com.crt
    

Then every mail sent to user@example.com using "mailx" will be encrypted using
S/MIME.

Got no local MTA installed? You can make mailx send the mail directly via
SMTP:

$ echo mail body | mailx -s "subject" -S smtp=mail.example.com:25 -S smtp-use-
starttls user@example.com

~~~
gravypod
That's still vulnerable to coldboot style attacks. If the data is never
unencrypted unless you're readining it that's technically safer. But yes you
are right that would work as well.

~~~
Tepix
Hawkpost (the project introduced here) is also vulnerable to a coldboot attack
- if the server that sends the page with the javascript is compromised, all
bets are off.

~~~
jsingleton
You need to trust the server at some point. Assuming you do then it doesn't
matter if the at-rest encryption is done in the browser or on the server.

I'd be happy with HTTPS upload and PGP encryption before writing to disk or
forwarding. I think the biggest risk of a secure upload server is a
vulnerability exposing a disk full of secure content in the future.

~~~
EGreg
Your don't need to trust the server. You can implement subresource integrity
checks!

~~~
nsgi
Subresource integrity still requires you to trust the server sending the
hashes.

~~~
EGreg
Ok so publish the hashes on a blockchain and have the client verify them there

~~~
rudolf0
Not a bad idea, but this isn't a thing browsers currently do, and the average
person can't do that with ease. Especially considering this web app is aimed
at non-tech savvy individuals.

~~~
roblabla
Make the whole page hosted on IPFS, and make your DNS point to it. Then you
just need to trust the DNS. So use namecoin.

------
dkopi
The weakest link I can identify here is MITM attacks when you're sending the
link.

Imagine:

    
    
      Alice generates a link. 
      Sends the link to Bob over an unencrypted/unauthenticated link.
      Mallory intercepts the link. Generates his own link and send that link to bob.
      Bob enters the confidential information on Mallory's link.
      Mallory sees the confidential information, and then sends it to Alice's original link.
    

The only way to prevent this type of attack is sending the link over a secure
channel. But if you already have a secure channel - what's the use case?

~~~
rhaps0dy
>But if you already have a secure channel - what's the use case?

You can use Whatsapp, or some other E2E-encrypted service that is easy to use,
and then transmit the sensitive data over encrypted email, which is more
convenient for long-form text.

~~~
dkopi
Personally, I find the Whatsapp web version pretty convenient for long-form
text

~~~
jsingleton
For text yes, but not so much for sending attachments like documents or other
arbitrary files.

------
dethos
Hi, I'm one of the contributors of the project and we started this because of
the need to deal with clients sending us information through insecure
channels. We have been using it for a while at Whitesmith and it entered our
team's workflow smoothly.

Please feel free to ask any question and I will try to answer the best I can.

Note: The project is open-source so you can self-host it. Contributions are
welcome.

Edit: to fix typo

~~~
jsingleton
This is a great idea but I often have this problem the other way around.

I regularly want to send encrypted data to companies that don't know how to
decrypt it. The number of firms that ask for sensitive info to be emailed
across (or not much better - use dropbox) is crazy.

Anyone got any good solutions to this?

~~~
burkaman
Does a password-protected zip file work?

~~~
jsingleton
This is the most basic step, but even this is non-trivial. There are multiple
ways of password protecting a zip, ZipCrypto is insecure and not all software
supports AES-256. Self-extractors will get stopped by AV and sometimes even
password protected zips (as the AV can't read them).

You then have to communicate the password out-of-band, as emailing it would
defeat the purpose. It may be hard to read over the phone and you have to
trust it was not written down and the file is not then stored/forwarded
unencrypted. Explaining the process to someone non-technical may be
challenging.

Symmetric crypto is a mess, asymmetric would be great if secure key exchange
could be easy. If only the software was as ubiquitous as zip handling is in
the OS.

~~~
srpeck
Microsoft solves this with RMS for Individuals:
[https://portal.aadrm.com/](https://portal.aadrm.com/) (also called the RMS
Sharing App, now getting rebranded to Azure Information Protection).

The recipient's identity is the key to opening the content - no need to
communicate anything out-of-band. Depending on the file format chosen, you get
DRM features limiting granular actions on the file beyond view/edit.

To open the protected files, your recipients will have to download/install the
(free) app from Microsoft. This is generally pretty painless.

Definitely worth checking out, especially good for consultants' workflows.

~~~
jsingleton
This actually looks like it might be the least-worst solution, thanks!

This is the product page: [https://www.microsoft.com/en-us/cloud-
platform/azure-informa...](https://www.microsoft.com/en-us/cloud-
platform/azure-information-protection)

------
OJFord

        >  or use the official server (that is running an exact copy of this repo)
    

Is there any project that attempts to prove claims like this?

I don't know what that would look like; it would probably just move the point
of trust, just interested to see it if such a thing exists.

~~~
bugmen0t
What you are looking for is called "remote attestation".

(In open source software the solution to this problem is "well, you could
always just host your own instance" ;))

~~~
OJFord

        > In open source software the solution to this problem is
        > "well, you could always just host your own instance"
    

That doesn't always work though - end-users can't trust you more because you
host it instead of using the version hosted by the OSS team for whom it's the
main focus. (Arguably they should actually trust the latter more!)

Consider Keybase for example. If someone builds a service on top of Keybase,
their end-users can't trust them with their private keys* if they host it
themselves instead of using upstream hosting.

*I know this is not required in order to use Keybase - I use it with gnupg and keep my keys local. It's the easiest example of needing to trust Keybase, though.

------
tptacek
This is actually an extremely common kind of enterprise security product ---
though none of them do the Javascript/PGP dance.

Enterprise security teams know, of course, that email is insecure, and that
partners and clients want to send sensitive stuff via email. So they buy these
products and stand them up, and then instruct their partners to follow a link
to upload their documents or sensitive emails, rather than using their email
client.

The box itself forwards the email to user inside the enterprise.

I think there's something useful here, but, like 'Tepix said: a simple form on
an HTTPS site is already doing 99.999% of the useful work here (that's all the
expensive enterprise products do, too).

A direction you can take this to be even more useful is to strip and sanitize
attachments, as a way of quarantining malicious email.

------
arnoxmp
Like several others I made a similar tool years ago :
[https://transfer.pw/](https://transfer.pw/)

It uses client side encryption, dyn. created keys, and the message is deleted
after first retrieval.

A slightly different usecase than the OP, still using it for all my clients.

------
diasp
Similar project [https://encrypt.to](https://encrypt.to)

~~~
nspassov
This is handy but I don't find it particularly pleasant that my email address
would be written in plain text on the web page. A service like keybase.io
helps with the key discovery and encryption part while not revealing my email
address in such a way.

------
sjs382
I built something like this in 2015 that didn't gain a ton of traction:
[https://privateforms.com](https://privateforms.com)

~~~
jsingleton
That looks cool. I think you might get better traction by selling it to
businesses such as solicitors and brokers. You could white-label it with their
branding and host it for them on a sub-domain - upload.low-tech-
accountants.com.

~~~
sjs382
Yeah, it's hard to find a market for this.

One unique proposition that Private Forms has is a form-builder so you can
create custom forms rather than just contact forms.

------
erikb
If you can get the library to the sender's browser without security problems
then it probably can securely encrypt the text and send it to the target. But
is it always secure to send someone the library that you want to use?

~~~
dethos
Your point is valid and the project should always run through HTTPS (with
HSTS). All assets are served from the local server.

------
leni536
js crypto's trust problem isn't solved yet. One has to trust hawkpost.co to
not serve compromised client side js.

~~~
edejong
Yes, there is no JS source signing in the browser yet. Then again, do you
check the (compiled) code that is delivered to you via source repositories
with which you sign/encrypt your GPG messages? How many people read the
OpenSSL source code? How trustworthy are the signatures on Debian packages?

~~~
haywirez
What about SRI?

"Subresource Integrity (SRI) is a security feature that enables browsers to
verify that files they fetch (for example, from a CDN) are delivered without
unexpected manipulation. It works by allowing you to provide a cryptographic
hash that a fetched file must match."

[0] [https://developer.mozilla.org/en-
US/docs/Web/Security/Subres...](https://developer.mozilla.org/en-
US/docs/Web/Security/Subresource_Integrity)

~~~
StavrosK
SRI is a great way to make an html page that loads all the js from a server,
tell the user to store that locally, and be sure that the loaded js files will
never change (otherwise they won't get loaded).

~~~
eli
Why not just store all the js locally too?

~~~
StavrosK
Purely for UX, it's easier to say "save the page you're currently viewing"
than "save this page and also these files". It's not a huge difference,
though, as you noted.

------
lisper
Here's another very similar project:

[https://github.com/Spark-Innovations/SC4](https://github.com/Spark-
Innovations/SC4)

Live demo:

[https://sc4.us/sc4/sc4tk.html](https://sc4.us/sc4/sc4tk.html)

SC4 has been through a security audit.

------
rev112
Looks great, this is something that is missing from Keybase (specifically, the
email sending part).

~~~
jlbribeiro
Hi, one of Hawkpost contributors here.

We actually use Keybase as well, and that was one of our inspirations for the
exact same reasons! Since one of our main use-cases was to receive secure data
from non-tech-savvy people we wanted to remove as much friction as possible,
and that included sending the encrypted blob. We're actually thinking of ways
of integrating Hawkpost with Keybase.io, namely fetching/verifying keys (as we
already do with keyservers).

------
tomw1808
Ha, the use-case reminds me of something I wrote a few months back.

A complete in-browser RSA encrypted message sharing for one-time use. Like
transferring passwords via unsecure channels (aka Skype).

It generates a keypair in the browser (offline) and guides also unexperienced
users through the process. Frankly, its a dirty hack, but it does the job
haha.

[http://tomw1808.github.io/rsa-message-
sharing/#/](http://tomw1808.github.io/rsa-message-sharing/#/)

------
arj
This is really smart, especially with something like protonmail.

------
internetwache
Not sure if I understood it correctly, but in essence it lets your users enter
some (secret) content which is then encrypted in the browser using PGP.

Except for the message signing and auto-emailing, I've implemented something
similar:

Blogpost: [https://0day.work/easy-pgp-composer-encrypting-pgp-
messages-...](https://0day.work/easy-pgp-composer-encrypting-pgp-messages-in-
your-browser/)

GitHub: [https://github.com/gehaxelt/PHP-Easy-PGP-
Composer](https://github.com/gehaxelt/PHP-Easy-PGP-Composer)

Demo: [http://pgpcomposer.demo.0day.work/](http://pgpcomposer.demo.0day.work/)

------
sametmax
I usually use a burn-after reading paste in 0bin.net for that, but I like the
idea of sending an email. Altough it could be use for spam don't you think ?

~~~
dethos
That was one of our concerns, to receive information you can setup different
"boxes" with an expiration date. Each box as an hard to guess url (such as
[https://hawkpost.co/box/19f1e7b9-f200-47ec-b5ff-918a9483a546](https://hawkpost.co/box/19f1e7b9-f200-47ec-b5ff-918a9483a546)),
so only the people you shared it with, will know how to access it.

You can also set the maximum number of messages you wish to receive through
that box.

I think these measures will help users avoid spam.

------
Odenwaelder
This is excellent and very helpful for my volunteer work.

------
empath75
I feel like you could knock out something similar to this using Vault, from
hashicorp.

~~~
dethos
Vault is an awesome tool, but I'm not sure if it lets an "outsider" submit
information in an easy way.

Some sort of integration with vault looks like a nice idea.

------
bartl
Python and PostGreSQL. Not exactly a tiny footprint for a tiny application.

~~~
dom0
C and flat files would've been a clearly better choice, I agree.

~~~
elcct
Whoa, Whoa... assembler and raw drive access only...

------
teaearlgraycold
I'm curious, when is this level of security necessary for civilians?

~~~
delinka
Always. All the time. Every day.

Lest your unencrypted messages one day be used in a fishing expedition to
facilitate oppression at the hands of the current political regime.

------
ComodoHacker
How is this different from e2e-encrypted webchat?

~~~
willvarfar
its store-and-forward?

~~~
dethos
on hawkpost the encrypted blob only goes through the sending queue and is
never stored permanently on the machine.

------
dvh

        $ echo "Hello world" > message.txt
        gpg --sign message.txt
    
        $ gpg --verify message.txt.gpg
        gpg: Signature made Wed 19th october 2016, 12:19:19 CEST using RSA key ID D9AE6E9E
        gpg: Good signature from "John Smith <john.smith@example.com>"
    
        $ echo "evil" > message.txt
    
        $ gpg --verify message.txt.gpg
        gpg: Signature made Wed 19th october 2016, 12:19:19 CEST using RSA key ID D9AE6E9E
        gpg: Good signature from "John Smith <john.smith@example.com>"

~~~
martin-adams
I don't think I'm smart enough to infer what you're trying to say. Care to
elaborate?

~~~
StavrosK
He's saying that, even though he changed the message, the signature still
validated. He doesn't realize that the resulting GPG file contains the
message, so it's verifying it against its own, stored copy.

~~~
Freak_NL
I think _dvh_ is confused about detached signatures and signatures that
contain their payload.

For detached signatures:

    
    
        gpg --verify message.sig message
    

For signed files:

    
    
        gpg --verify message.sig
        gpg --output message --decrypt message.sig
    

It's all documented¹.

Dvh: what are you getting at?

1:
[https://www.gnupg.org/gph/en/manual/x135.html](https://www.gnupg.org/gph/en/manual/x135.html)

~~~
dvh
I'm just trying to point out that it is easy to make mistake by checking
normal signature and detached signature.

