Tier Nolan [ARCHIVE] on Nostr: š Original date posted:2014-01-03 š Original message:On Fri, Jan 3, 2014 at ...
š
Original date posted:2014-01-03
š Original message:On Fri, Jan 3, 2014 at 9:59 AM, Drak <drak at zikula.org> wrote:
> Which is why, as pointed out several times at 30c3 by several renowned
> figures, why cryptography has remained squarely outside of mainstream use.
> It needs to just work and until you can trust the connection and what the
> end point sends you, automatically, it's a big fail and the attack vectors
> are many.
>
> <sarcasm>I can just see my mother or grandma manually checking the hash of
> a download... </sarcasm>
>
Maybe a simple compromise would be to add a secure downloader to the
bitcoin client.
The download link could point to a meta-data file that has info on the
download.
file_url=
hash_url=
sig_url=
message=This is version x.y.z of the bitcoin client
It still suffers from the root CA problem though. The bitcoin client would
accept Gavin's signature or a "core team" signature.
At least it would provide forward security.
It could also be used to download files for different projects, with
explicit warnings that you are adding a new trusted key.
When you try to download, you would be given a window
Project: Some Alternative Wallet
Signed by: P. Lead
Message:
Confirm download Yes No
However, even if you do that, each trusted key is only linked to a
particular project.
It would say if the project and/or leader is unknown.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140103/5294c903/attachment.html>
š Original message:On Fri, Jan 3, 2014 at 9:59 AM, Drak <drak at zikula.org> wrote:
> Which is why, as pointed out several times at 30c3 by several renowned
> figures, why cryptography has remained squarely outside of mainstream use.
> It needs to just work and until you can trust the connection and what the
> end point sends you, automatically, it's a big fail and the attack vectors
> are many.
>
> <sarcasm>I can just see my mother or grandma manually checking the hash of
> a download... </sarcasm>
>
Maybe a simple compromise would be to add a secure downloader to the
bitcoin client.
The download link could point to a meta-data file that has info on the
download.
file_url=
hash_url=
sig_url=
message=This is version x.y.z of the bitcoin client
It still suffers from the root CA problem though. The bitcoin client would
accept Gavin's signature or a "core team" signature.
At least it would provide forward security.
It could also be used to download files for different projects, with
explicit warnings that you are adding a new trusted key.
When you try to download, you would be given a window
Project: Some Alternative Wallet
Signed by: P. Lead
Message:
Confirm download Yes No
However, even if you do that, each trusted key is only linked to a
particular project.
It would say if the project and/or leader is unknown.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140103/5294c903/attachment.html>