[HN Gopher] A Criticism of JavaScript Cryptography
       ___________________________________________________________________
        
       A Criticism of JavaScript Cryptography
        
       Author : ementally
       Score  : 20 points
       Date   : 2023-03-05 18:47 UTC (4 hours ago)
        
 (HTM) web link (blog.bren2010.io)
 (TXT) w3m dump (blog.bren2010.io)
        
       | codeflo wrote:
       | This seems to argue that accessing a web app (assuming an
       | important piece of software that handles private encrypted data)
       | is no less secure than loading software from a package
       | repository, because a web server requesting the JavaScript and a
       | software updater loading binary code from a server is
       | structurally identical.
       | 
       | The obvious response to this is offline signatures: For package
       | managers, app stores, updaters and the like, the integrity of the
       | update server itself doesn't really matter, because the installer
       | verifies a cryptographic signature from an offline key.
       | 
       | This argument is acknowledged, but seems to be dismissed without
       | a real explanation:
       | 
       | > More astutely, there's also the distinction that either a file
       | system compromise or a key compromise is required to serve
       | malicious code to users with TLS, but software repositories can
       | be architected such that a key compromise is required, through
       | the implementation of offline keys. Despite this, though, there
       | are several examples of secure software repositories that
       | successfully use TLS. This isn't a grave concern (and they
       | probably won't be converting soon) because the decision to use
       | offline keys is palliative, at best, and only marginally
       | increases a system's level of security.
       | 
       | > However, I openly concede that there are cases where a software
       | repository can offer a higher level of security than a browser is
       | currently capable of. I plan to discuss this later.
       | 
       | AFAICT, this "later" doesn't happen in this article, though I
       | might have missed something. I really don't see why offline
       | signatures are only "palliative". Web servers are hacked all the
       | time, DNS misconfigurations happen, but organizations losing
       | control of their software signature keys is comparatively rare.
       | Why would you give up a very effective level of defense if it's
       | so easily available?
        
       | dgl wrote:
       | I'd really like to see something like
       | https://engineering.fb.com/2022/03/10/security/code-verify/
       | become a more standard part of browsers. i.e. a standard way to
       | go from sub-resource integrity to "full integrity".
       | 
       | Having it as an extension just moves the weak point to the
       | extension update mechanism.
       | 
       | Of course apps can just distribute themselves as an extension
       | which is probably the best compromise right now and something
       | most web based password managers for example already offer.
        
       | franky47 wrote:
       | > Do "secure keystores" just not exist?
       | 
       | Probably not if we consider threat models evolving in the same
       | userspace as where they're implemented (eg as cited: keyloggers
       | and malicious native programs).
       | 
       | HSMs may provide an entrypoint to the "root of secrecy" problem,
       | though the way they interface with the system now becomes the
       | single point of defense.
        
       | woodruffw wrote:
       | (2014).
       | 
       | This is a response to Matasano's "JavaScript Cryptography
       | Considered Harmful"[1], except Matasano no longer exists and the
       | link in the post 404s.
       | 
       | Archived[2].
       | 
       | [1]: https://matasano.com/articles/javascript-cryptography/
       | 
       | [2]:
       | https://web.archive.org/web/20120414231547/https://matasano....
        
         | thayne wrote:
         | Ah, the reference to http 3.0 not existing for hundreds of
         | years makes a lot more sense knowing it is from 2014
        
       ___________________________________________________________________
       (page generated 2023-03-05 23:00 UTC)