December 2021 - cypherpunks - lists.cpunks.org

Rupert Murdoch needs killing
by professor rat 22 Dec '21

22 Dec '21

He's such a bad example for other Aussie publisher / journalists Fauci calls for Fox News host to be fired 'on the spot' for 'kill shot' comments CNN 39 minutes ago ‘The guy should be fired on the spot’: Fauci rebukes Fox News host over violent rhetoric POLITICO 1 hour ago

1 0

Assassinphones gone wild
by professor rat 22 Dec '21

22 Dec '21

When bad things happen to good assassinphone's gregpmiller · 6h A UAE agency put Pegasus spyware on phone of Jamal Khashoggi’s wife months before his murder, new forensics show https://washingtonpost.com/nation/interactive/2021/hanan-elatr-phone-pegasu…

1 0

Hackaday: All Hail Your New Giant 555 Timer Overlord
by jim bell 22 Dec '21

22 Dec '21

Hackaday: All Hail Your New Giant 555 Timer Overlord. https://hackaday.com/2021/12/20/all-hail-your-new-giant-555-timer-overlord/

2 1

The Guardian: US ‘closer to civil war’ than most would like to believe, new book says
by jim bell 22 Dec '21

22 Dec '21

The Guardian: US ‘closer to civil war’ than most would like to believe, new book says. https://www.theguardian.com/us-news/2021/dec/20/us-closer-to-civil-war-new-…

2 1

Jupiters moon sounds like a brave little droid
by professor rat 21 Dec '21

21 Dec '21

In contrast to Jim Dumbell who now sounds more and more like Jar Jar Binks. I shouldn't have come on this mission.

1 0

Jupiter moon sounds like a dial-up modem in eerie NASA audio
by jim bell 21 Dec '21

21 Dec '21

Jupiter moon sounds like a dial-up modem in eerie NASA audio https://share.newsbreak.com/9h0vk6ji Jim Bell's comment: "The number you have dialled is interplanetary. Please insert an additional 5,729 quarters into your phone and dial again."

1 0

Ristretto
by coderman 21 Dec '21

21 Dec '21

https://ristretto.group/ Ristretto is a technique for constructing prime order elliptic curve groups with non-malleable encodings. It extends Mike Hamburg's [Decaf](https://www.shiftleft.org/papers/decaf/) approach to cofactor elimination to support cofactor-$8$ curves such as Curve25519. In particular, this allows an existing Curve25519 library to implement a prime-order group with only a thin abstraction layer, and makes it possible for systems using Ed25519 signatures to be safely extended with zero-knowledge protocols, with no additional cryptographic assumptions and minimal code changes. Ristretto can be used in conjunction with Edwards curves with cofactor $4$ or $8$, and provides the following specific parameter choices: - ristretto255, built on top of Curve25519. Background Many cryptographic protocols require an implementation of a group of prime order $ \ell $, usually an elliptic curve group. However, modern elliptic curve implementations with fast, simple formulas don't provide a prime-order group. Instead, they provide a group of order $h \cdot \ell $ for a small cofactor, usually $ h = 4 $ or $ h = 8$. In many existing protocols, the complexity of managing this abstraction is pushed up the stack via ad-hoc protocol modifications. But these modifications are a recurring source of vulnerabilities and subtle design complications, and they usually prevent applying the security proofs of the abstract protocol. On the other hand, prime-order curves provide the correct abstraction, but their formulas are slower and more difficult to implement in constant time. A clean solution to this dilemma is Mike Hamburg's [Decaf proposal](https://eprint.iacr.org/2015/673.pdf), which shows how to use a cofactor-$4$ curve to provide a prime-order group – with no additional cost. This provides the best of both choices: the correct abstraction required to implement complex protocols, and the simplicity, efficiency, and speed of a non-prime-order curve. However, many systems use Curve25519, which has cofactor $8$, not cofactor $4$. Ristretto is a variant of Decaf designed for compatibility with cofactor-$8$ curves, such as Curve25519. It is particularly well-suited for extending systems using Ed25519 signatures with complex zero-knowledge protocols. Pitfalls of a cofactor Curve cofactors have caused several vulnerabilities in higher-layer protocol implementations. The abstraction mismatch can also have subtle consequences for programs using these cryptographic protocols, as design quirks in the protocol bubble up—possibly even to the UX level. The malleability in Ed25519 signatures [caused a double-spend vulnerability](https://moderncrypto.org/mail-archive/curves/2017/000898.htm…, technically, octuple-spend as $ h = 8$—in the CryptoNote scheme used by the Monero cryptocurrency, where the adversary could add a low-order point to an existing transaction, producing a new, seemingly-valid transaction. In Tor, Ed25519 public key malleability would mean that every v3 onion service has eight different addresses, causing mismatches with user expectations and potential gotchas for service operators. Fixing this required [expensive runtime checks](https://trac.torproject.org/projects/tor/ticket/22006#comment:13) in the v3 onion services protocol, requiring a full scalar multiplication, point compression, and equality check. This check [must be called in several places](https://github.com/torproject/tor/search?q=hs_address_is_valid&unsc… to validate that the onion service's key does not contain a small torsion component. Why can't we just multiply by the cofactor? In some protocols, designers can specify appropriate places to multiply by the cofactor $h$ to "fix" the abstraction mismatches; in others, it's unfeasible or impossible. In any case, multiplying by the cofactor often means that security proofs are not cleanly applicable. As touched upon earlier, a curve point consists of an $ h $-torsion component and an $ \ell $-torsion component. Multiplying by the cofactor is frequently referred to as "clearing" the low-order component, however doing so affects the $ \ell $-torsion component, effectively mangling the point. While this works for some cases, it is not a validation method. To validate that a point is in the prime-order subgroup, one can alternately multiply by $ \ell $ and check that the result is the identity. But this is extremely expensive. Another option is to mandate that all scalars have particular bit patterns, as in X25519 and Ed25519. However, this means that scalars are no longer well-defined $ \mathrm{mod} \ell $, which makes HKD schemes [much more complicated](https://moderncrypto.org/mail-archive/curves/2017/000858.html). Yet another approach is to choose a [torsion-safe representative](https://moderncrypto.org/mail-archive/curves/2017/000866.ht…: an integer which is $ 0 \mathrm{mod} h $ and with a particular value $ \mathrm{mod} \ell $, so that scalar multiplications remove the low-order component. But these representatives are a few bits too large to be used with existing implementations, and in any case aren't a comprehensive solution. A comprehensive solution Rather than bit-twiddling, point mangling, or otherwise kludged-in ad-hoc fixes, Ristretto is a thin layer that provides protocol implementors with the correct abstraction: a prime-order group. What is Ristretto? Ristretto is a construction of a prime-order group using a non-prime-order Edwards curve. The Decaf paper suggests using a non-prime-order curve $\mathcal E$ to implement a prime-order group by constructing a quotient group. Ristretto uses the same idea, but with different formulas, in order to allow the use of cofactor-$8$ curves such as Curve25519. Internally, a Ristretto point is represented by an Edwards point. Two Edwards points $P, Q$ may represent the same Ristretto point, in the same way that different projective $ X, Y, Z $ coordinates may represent the same Edwards point. Group operations on Ristretto points are carried out with no overhead by performing the operations on the representative Edwards points. To do this, Ristretto defines: - a new type for Ristretto points which contains the representative Edwards point; - equality on Ristretto points so that all equivalent representatives are considered equal; - an encoding function on Ristretto points so that all equivalent representatives are encoded as identical bitstrings; - a decoding function on bitstrings with built-in validation, so that only the canonical encodings of valid points are accepted; - a map from bitstrings to Ristretto points suitable for hash-to-point operations. In other words, an existing Edwards curve implementation can implement the correct abstraction for complex protocols just by adding a new type and three or four functions. Moreover, equality checking for the Ristretto group is actually less expensive than equality checking for the underlying curve! The Ristretto construction is described and justified in detail in the [next chapter](https://ristretto.group/details/index.html), and explicit formulas aimed at implementors are in the [Explicit Formulas](https://ristretto.group/formulas/index.html) chapter. ...

2 2

Fwd: xNY.io | Harvard Management Company
by Gunnar Larson 21 Dec '21

21 Dec '21

The Saga Continues... -- *Gunnar Larson - xNY.io <http://www.xny.io/> | Bank.org <http://bank.org/>* MSc <https://www.unic.ac.cy/blockchain/msc-digital-currency/?utm_source=Google&u…> - Digital Currency MBA <https://www.unic.ac.cy/business-administration-entrepreneurship-and-innovat…> - Entrepreneurship and Innovation (ip) G(a)xNY.io +1-646-454-9107 New York, New York 10001 ---------- Forwarded message --------- From: Ben Edelman <ben(a)benedelman.org> Date: Thu, Nov 25, 2021 at 5:37 PM Subject: Re: xNY.io | Harvard Management Company To: Gunnar Larson <g(a)xny.io> Cc: Alexi Anania <a(a)xny.io> I'm sorry, but I just can't assist. My new employment requires my full time and attention, and does not allow side projects like this. Good luck! On Thu, Nov 25, 2021 at 1:26 PM Gunnar Larson <g(a)xny.io> wrote: > Dear Ben: > > How are you? Hope you are enjoying a good Holiday weekend. > > In other news, totally understand your consultancy may be currently fully > committed, but wanted to check-in with you on STX's potential strategic > manipulation of Bitcoin's blockchain software and/or technology. > > Harvard Management Company has close association to STX. > > From xNY.io - Bank.org's perspective CityCoin's $100M+ mining operation > with recent NYCCoin announcement may be the largest virtual currency fraud > of modern time. > > Harvard Management Company once held a $200M Board Advisory role at STX. > > MIA Coin and NYCCoin are minted from STX's potential computer software > crimes, such as perhaps manipulating blockchain computer technology. > > What is worth asking is, what (if anything) does Harvard Management > Company have to do with this? > > *Blockstack Token LLC (2019):* > > > "In connection with the sale to the QP Fund, we have formed a token > advisory board, the LP Advisory Committee, the main purpose of which is to > determine whether the above milestones have been met. The token advisory > board consists of seven members. Three of the members, Charlie Saravia, > Zavain Dar and Rodolfo Gonzalez are designees of affiliates of the Harvard > Management Company, Lux Capital and Foundation Capital, respectively, > limited partners of the QP Fund which have purchased an aggregate of > 95,833,333 Stacks Tokens; ..." > > Mr. Saravia is the Managing Director at Harvard Management Company (2017 - > Present): https://www.linkedin.com/in/charliesaravia > > Before Harvard, Mr. Saravia was Managing Director at P1 Capital in Miami > (2014 - 2017): https://www.linkedin.com/company/p1-capital-llc > > STX denies being involved with MIA Coin, NYCCoin and CityCoins (ran by > former STX Head of Growth). So it could be totally bogus to simply wonder > about Harvard Management Company having anything to do with all this? > > Professor Steven Hawking states, “A theory is a good theory if it > satisfies two requirements. It must accurately describe a large class of > observations on the basis of a model that contains only a few arbitrary > elements, and it must make definite predictions about the results of future > observations... But if the theory was mathematically consistent and always > gave predictions that agreed with observations, we could be reasonably > confident that it was the right one...” > > xNY.io has no real desire to tiptoe around the tulips with NYCCoin. Seems > like STX and Harvard Management Company would never be unrelated > co-conspirators with MIA Coin, right? > > Ben, what do you think? > > Sending you the very best regards. > > Thank you, > > Gunnar > -- > *Gunnar Larson - xNY.io <http://www.xny.io/> | Bank.org <http://bank.org/>* > MSc > <https://www.unic.ac.cy/blockchain/msc-digital-currency/?utm_source=Google&u…> - > Digital Currency > MBA > <https://www.unic.ac.cy/business-administration-entrepreneurship-and-innovat…> - Entrepreneurship > and Innovation (ip) > > G(a)xNY.io > +1-646-454-9107 > New York, New York 10001 >

1 0

JPMorgan’s Crime Wave Continues, Calling into Question the Justice Department’s Lax Settlement with the Bank Last Year
by Gunnar Larson 21 Dec '21

21 Dec '21

JPMorgan Chase is the largest bank in the United States. It also has the scandalous distinction of having admitted to five criminal felony counts brought by the U.S. Department of Justice since 2014 and a breathtaking series of additional charges from other regulators. (See its Rap Sheet here <https://wallstreetonparade.com/12259-2/>.) On Friday, the Securities and Exchange Commission fined the securities unit of JPMorgan Chase $125 million for evading the ability of the SEC to adequately conduct its investigations of the bank because there was “firmwide” use by traders, supervisors and other personnel of non-official communications devices to conduct its business, while the firm failed to record and retain these messages as required by law. https://wallstreetonparade.com/2021/12/jpmorgans-crime-wave-continues-calli… -- *Gunnar Larson - xNY.io <http://www.xNY.io> | Bank.org <http://Bank.org>* MSc <https://www.unic.ac.cy/blockchain/msc-digital-currency/?utm_source=Google&u…> - Digital Currency MBA <https://www.unic.ac.cy/business-administration-entrepreneurship-and-innovat…> - Entrepreneurship and Innovation (ip) G(a)xNY.io +1-646-454-9107 New York, New York 10001

1 0

Goose
by Gunnar Larson 20 Dec '21

20 Dec '21

1. 2. NORTH AMERICAN give (something) a boost; invigorate; increase. "the director *goosed up* the star's grosses by making him funny"

1 0