Telegram Web Link
All Messages Have Been Answered On All Platforms

1. Answered all pending messages here on Telegram

2. Answered all pending messages on Discord / Riot

3. Answered all pending messages on Twitter as well

So if you've sent out a message to Librehash in the recent past, and you're awaiting a response to your message - you should check your inbox at your earliest convenience, because all messages have officially been answered at the time of this post's sending.
Obtained a .ETH Name

We officially have reserved 'librehash.eth' ; feel free to get in contact and say 'Hey' :)
Issue Created on the Roundcube GitHub (directed at Enigma Plugin / Enigmail)

You can find it here: https://github.com/roundcube/roundcubemail/issues/7473

Main Goal

Get this developer to tell us how to generate these keys (through the user interface in specific - solutions that are terminal-based do not apply here).

There's no reason why this should not be feasible in 2020 with a semi-modern ish browser.
Librehash ANN
Issue Created on the Roundcube GitHub (directed at Enigma Plugin / Enigmail) You can find it here: https://github.com/roundcube/roundcubemail/issues/7473 Main Goal Get this developer to tell us how to generate these keys (through the user interface in…
They already responded to this issue - closed the ticket, then redirected it here: https://github.com/roundcube/roundcubemail/issues/6853 (fair enough).

However, they are still being incredibly unhelpful.

Yes, I question the motives of this developer and any other entity in this world that finds the security of their users to be a optional consideration.

We Will Not Abandon This Idea

The Librehash Mail solution could be so much better if the code were modified to allow for this - because it would allow users (for the first time) to take complete control of their GPG key management in the easiest way possible (more than likely, easier than generating and managing a really cryptocurrency wallet)
New Platform Release: 'OneDev'

Integration and Release Guide Coming Soon

Above is a screenshot of what the platform looks like.
Petitioning the Maintainer of 'Gocryptfs' to Import Argon2id Hashing Alongside Scrypt (or as a drop-in replacement)

Follow along with the issue here: https://github.com/rfjakob/gocryptfs/issues/520

Why you should care

Because I wrote up a mean script for this that allows for the creation of super secure gpg keys, w a private key encryption passfile that's ephemerally generated in 'RAM' in a stateless manner using a generic password (of your choosing) as the 'input'

I am going to abstract this onto a GUI that users can navigate using Jupyter Lab for a teaching experience / demo, then I'll make it a shiny, clean app.

Modern commercial (+ open source) password managers, vaults, cloud storage, etc., is woefully lacking when it comes to security parameters, and I hate that. I want to use the best cryptographic schemes available and utilize the libraries, code, & published cryptographic schemes available to us to their fullest extent - why not?
Closed Down the Previous Issue on 'Gocryptfs' and Opened Up Another One Declaring the Use of 'Scrypt' in Gocryptfs is a Vulnerability

Full stop.

This didn't need to be covertly relayed to the maintainer of that project because there is more than enough public information re: the shortcomings of Scrypt and there have been others that have brought up the inclusion of Argon2 as either an alternatives or an outright replacement for Scrypt.

The issue can be found here: https://github.com/rfjakob/gocryptfs/issues/522
Librehash ANN
Closed Down the Previous Issue on 'Gocryptfs' and Opened Up Another One Declaring the Use of 'Scrypt' in Gocryptfs is a Vulnerability Full stop. This didn't need to be covertly relayed to the maintainer of that project because there is more than enough…
Subsequent Measures

1. Will open up another issue that briefly breaks down the benefits / properties of Argon2 as a KDF (specifically the many that Scrypt fails to provide). In addition, the fact that there are three instantiations of this KDF that, in itself, serves as an adjustable parameter means that not only are users receiving superior security (comparative to Scrypt), more informed users are given the opportunity to tweak the algorithm in a way that flexibly addresses their unique threat environment / perceived adversary

2. Currently collaborating with the maintainer of gocryptfs on this (hopefully; the step-by-step breakdown of how to swap out Scrypt was done when this was first brought up to the lead maintainer as everyone can see above)

Pull Request Will Be Made Before the End of the Week

In my opinion, this should be considered a time sensitive issue because the successful implementation of a cache timing attack on someone using Scrypt means that they have put themselves in a position to viably extract the original password...and since this password is what gets piped into 'gocryptfs' to mount containers, the solution itself (file system encryption overlay) is equally as vulnerable since the password serves as the encryption / decryption key.
Katacoda Deployment Coming Soon

For those not familiar, Katacoda is most well-known (for me at least), for their hosting & always available 'Ubuntu Playgrounds'.

A 'playground' is essentially an "environment" that's containerized, sandboxed and ephemeral.

To simplify that, Katacoda provides access to a terminal that's running an OS like Ubuntu. The purpose of doing this is to allow users to practice running different commands or even spin up a project you came across on GitHub that you don't want to clone onto your personal computer / expose a localhost port to the internet.

These playgrounds come with full-blown, regularly featured Ubuntu instances. Obviously not without resource constraints imposed since this is free, but they give you a very, very generous & workable leash on it.

I've personally never had my connection to one of Katacoda's terminal throttled, and I've pulled in a few dozen GBs before in a session (don't be a dick & abuse this, these folks are providing a free service that helps folks out - they don't deserve to be punished for that)
Changes to the Website / Blog / Newsletter (librehash.org)

1. Added a new background to the top of the page

2. Added a 'search' feature

3. Reoriented a few tags

4. Combing through & editing a few pieces to amend spelling errors, formatting issues & other grammatical mistakes for clarity

5. Created a 'subscribers' page for any and all that are interested in getting these posts / updates straight to their inbox. No charge necessary. Nothing will ever be sent to said inbox except for a post update (won't even advertise the ephemeral membership package that we have going on currently)
Forwarded from Libre Blockchain
Telegram Chat Channel Changelog (@librehashdiscussion)

1. Reinstated the Combot in the chat, so a lot of the spam should be out of here from now on.

2. Auto-banned any accounts joining* saying something like "you wanna chat? :)" or some variation of that.

3. Users now have the option to report spam if any does manage to get through the cracks. You just need to type "/report" and the message you're reporting will be auto-DM'd to myself and other admins in the chat that will be able to ban that person immediately. In the event that neither myself or any other admins are on, spam + spammer will be temp removed for 24 hours if 3 or more reports are received. If users abuse that feature to have legitimate users banned, then they will be permanently banned.

4. Introduced a new 'rating' / 'reputation' system. Those that contribute good content in the chat can be upvoted by others, with those scores factoring into that user's overall reputation & rating in the chat. Soon this will translate into actual ranking in the chat. Those with a higher reputation will receive labels in the chat that reflect such.

Final Note

Still considering a bridged integration between this Telegram channel chat and a couple of other ones that are maintained by Librehash.
Forwarded from Libre Blockchain
For Those Sending a Letter to FinCEN on December 23rd, 2020 When Comments Open

FinCEN is expecting everyone to come at this from the obvious angle of 'privacy' / 'government overreach' etc., so we can expect that they'll hand wave those issues, citing "national security concerns".

The best way to come at this is to argue that these restrictions will ultimately undermine the Treasury in their goal of countering money laundering, terrorism financing, etc.

If we can provide some credible arguments that prove that, then the FinCEN has to take a step back and reconsider.

Fortunately, I've brainstormed some potential angles users should consider when submitting comments:

1. The average value per transaction on Bitcoin's blockchain = $111k (right now) and there are 10k+ transactions per day. More than likely, transactions that are worthy of scrutiny by FinCEN fall within that range rather than the $3,000 range. Thus, by mandating a $3000 reporting limit, FinCEN is introducing a ton of additional noise that could actually make it more difficult for them to hone in on the supposed suspicious transactions that they're looking to track.

2. Recently the government handed down a federal indictment on BitMex - a cryptocurrency exchange - for violating the Bank Secrecy Act. The New York Attorney General is still engaged with Bitfinex (crypto exchange) in a lawsuit that alleges they perpetrated several hundred million dollars worth of fraud. Mt. Gox, BTC-e and QuadrigaCX are three more potent examples of extreme malfeasance, negligence and BSA violations in blockchain. If FinCEN's goal is to really crack down on potential laundering and crime on the blockchain, wouldn't it make sense to hone in on the actions of these platforms specifically before focusing on these lower transaction amounts? Also, is it a wise idea to trust entities with such a piss poor track record of compliance to...be compliant with this measure?

3. What checks / audits are in place to ensure that exchanges do not attempt to falsify data? After all, an exchange could send out funds on its own behalf and claim that they were a withdrawal initiated by some random customer on their platform. Chances are, that customer and FinCEN would be none the wiser. Not only would this defeat the purpose of their proposed restrictions, it could potentially make it easier for exchanges to launder funds and facilitate the ACTUAL criminal activity.

4. How will FinCEN make intelligible use of this information? At the time of writing, certain exchanges have well over 50-100+ traded pairs. Is FinCEN insisting that each exchange keep track of each and every single customer as well as each and every single transfer to and from the exchange for each and every single currency offered on the exchange? And if so, how does the government plan on doing the same? (since it is assumed that FinCEN will be archiving this information for future usage).

5. Multi-signature wallets and 'P2SH' addresses are left entirely unaddressed in the order. Additionally, there are no restrictions imposed on which addresses one can withdraw to, which may make it even easier for one to obfuscate their identity. Imagine Joe and Fred both send 6 bitcoins to exchange A. That exchange logs those transfers. What controls are in place to restrict Joe from withdrawing to Fred's wallet? And if he does, do we log this as a transaction on Fred's behalf or is it for Joe? Or both? Or do we restrict Joe? And if we choose the lattermost option, how restricted is Joe? Can he only withdraw to a wallet he identifies with the exchange?
Forwarded from Libre Blockchain
6. Why does the FinCEN report leave out mining entirely? There is $150k-160k in value generated per block, which amounts $21.6 million generated per day (for Bitcoin). These funds are "coinbase" rewards for the miner with the winning nonce that finds it first at any given block height. Should that miner do KYC for their mining pool distributions now? How would they even go about doing so? And speaking of mining, what if there is large mining entity that is engaged in money laundering / violations of the Bank Secrecy Act? Are they just off the hook? Seems like the FinCEN restrictions never considered that.
Stay Far the Fuck Away From a Tool Called 'Linux Mortar' (developer is a child and a fucking idiot - let's be honest)

Here's the Git Repo for this crap = https://github.com/noahbliss/mortar/issues/11

IQ < 40 alert.

This individual does not understand the basic trappings of how the internet or encryption works.

There's absolutely no way in mankind that they're imbued with the qualities necessary to safely construct a project that cannot be easily bypassed and/or compromised.

If this child has done the initial work of at least figuring out the necessary steps / skeleton structure for a secure boot process, then I suppose that at least this can be considered a benefit.

Do not rely on this dipshit for anything meaningful though - go to the Arch Linux and refer to the notes that they have there. They are legitimate developers that actually know what the fuck they're talking about.

This person is a script kiddie (literally), with a middle schooler's undertanding of the internet and how it works. I will more than likely write up about this individual on my blog and publish it so that all can be warned to not waste their time with what could amount to garden variety malware (you know, because this kid does not understand how the internet works - he's never even heard of the IETF! Does not know how DNS works!! Thinks its some magic fairy in the sky that bestows the correct IP address mappings!

Everyone who read this message is being fucking saved. You're welcome and you've been duly warned.
Altered the definition of the 'Bitcoin v Ethereum' page on 'diffen.com' ; time to start inserting the truth in various regions of the internet.

Edit: This is the tough love that a lot of people don't want for these projects, but its what they need
2025/07/06 20:33:24
Back to Top
HTML Embed Code: