[HN Gopher] PurritoBin: Ultra fast, minimalistic, encrypted comm... ___________________________________________________________________ PurritoBin: Ultra fast, minimalistic, encrypted command line paste- bin Author : zdw Score : 48 points Date : 2020-07-04 23:41 UTC (23 hours ago) (HTM) web link (github.com) (TXT) w3m dump (github.com) | rakoo wrote: | > openssl enc blablabla | | _Don 't_ use that line for encrypting stuff. There is no | authentication and the IV is static. You're just asking for your | secrets to be decrypted or modified without anyone noticing | philplckthun wrote: | Genuinely ignorant here and curious, would using OpenSSL's salt | option help here? I'm not quite sure why the instructions in | the repo specify a fixed IV to begin with | slykar wrote: | > When you visit the html webpage the key is in the hash property | of the webpage, which is never sent to the server. | | So it's only safe if you trust the server, which kind of defies | the purpose? | joan_kode wrote: | The command line version actually allows you to "not trust the | server". But thinking it through I agree that the in-browser | version could get served a different JS that grabs the hash and | sends it to the server. This would be easily detectable, but it | does seem like problem with the concept. | nullc wrote: | > This would be easily detectable, but it does seem like | problem with the concept. | | I think it would be better to describe it as detectable but | not practically so. | | There have been many javascript "bitcoin wallet generators" | that defrauded users this way. In both cases where they were | backdoored from day one and cases where they changed the code | later (sometimes on the fly based on useragent and referrer!) | the detection has always been from users noticing their coins | were stolen. | | Its simply too difficult to review a javascript application | given the ubiquity of deeply nested superfluous dependencies | and toolkits-- and too pointless given that the code can be | selectively substituted any any time, so almost no one does | the review. | [deleted] | [deleted] | joan_kode wrote: | This is neat and has potential. But I was somewhat arrested by | this feature: | | " _all pastes are cleared daily at 1:30am EST, so you have 12 hrs | on average for your paste_ " | | So, 12 hours on average... zero seconds if you're unlucky. | philipkiely wrote: | Yeah, this is clearly a situation where average is not the most | meaningful metric. | CodeWriter23 wrote: | > zero seconds if you're unlucky. | | Predictably unlucky by putting your paste in at 1:30 EST. But | yeah, why not timestamp each record and give it a 24hr TTL? | vesche wrote: | http://ix.io/ ___________________________________________________________________ (page generated 2020-07-05 23:00 UTC)