Constant Time Miller-Rabin Test Added To Finite Field Arithmetic

Stanislav Datskovskiy (WOT: asciilifeform) has published code that adds a constant time implementation of the Miller-Rabin primality test to his Finite Field Arithmetic library as chapter 16A. He will publish a proof his algorithm implements Miller-Rabin and a discussion of the statistics informing proper use of the Miller-Rabin in the field as chapter 16B.

In his genesis of the FFA library Datskovskiy laid out his mission of creating a auditable bignum library whose entire operation is accessible to literate readers while avoiding optimization traps that add complexity or deviate from constant time operation opening up side channels that leak information intended to be kept secret. In the case of Werner Koch's MPI versus FFA, Datskovskiy's constant time implementation actually outperforms the optimized, variable time, legacy Koch library in in modular exponentiation.

At present FFA consists of 4013 non-empty lines of code in the libffa library of which 1835 are comments and 1047 non-empty lines of code in the accompanying ffacalc interface to the library of which 390 are comments.

Stanislav Datskovskiy Publishes Fully Constant Time Code For Barrett's Modular Reduction As Part Of FFA Library

As part of his Finite Field Arithmetic Library, Stanislav Datskovskiy1 (WOT: asciilifeform) has published code to perform Barrett's Modular Reduction in constant time. Speed of the code is favorable compared to Werner Koch's MPI library utilized in GPG. It appears that leaky optimizations of the sort that seem like they should make Koch's non-constant time implementation faster end up chewing quite a few clock cycles to accomplish an effect quite contrary to actual optimization.

  1. Involved as a principal in the Republican ventures No Such lAbs and Pizarro ISP.  

Eulora's New All-Time High Jackpot Trebles, Hits 3.5 BTC

Player Mircea Mircescu scored the biggest-ever "pop" in the history of Eulora, MiniGame's Bitcoin-denominated MMORPG, just past midnight server time on December 16th, 2017. Reigning the "Top of Pops" list in-game, the windfall weighs in at 3505.309 million ECu, or a hair over three and a half Bitcoin. The previous chart-topper occurred two years ago, also in December, at 1081.602 million ECu.

Mircescu's real-world avatar Mircea Popescu hinted at the pop's provenance in the game's IRC channel, #Eulora, where he stated the winning click occurred during a crafting run of "bod", or Black of Desspayr, a highly sought-after potion critical in the manufacture of blueprints for other items. Previous auction data for the item shows a markup of over 250% on the base price, which corresponds to the amount reported in-game for the pop –suggesting the market value of Mircescu's winnings likely exceed 8.5 billion ECu.

The pop comes on the heels of major events in Eulora's development, including the unfolding of an Ada-implemented communication protocol and an improved crafting and exploring bot refined by players to ease the hands-on aspect of in-game activities.

Node.js "event-stream" Library Added Bitcoin Wallet Stealer After New Maintainer Takes Over

The "popular" node.js "event-stream" library was loaded with a module stealing from Bitpay's Copay Bitcoin wallet after creator and longtime maintainer Dominic Tarr handed maintenance over to an unknown identifying itself with the text string "right9ctrl" (archived). Before the handover right9ctrl made a couple of contributions to event-stream building rapport with Tarr. After getting the keys to the repository right9ctrl added a dependency in event-stream on a new "flatmap-stream" library which had been distributed in an encrypted form, which should itself have been a warning if anyone had been bothering to read code they run. Instead it took two months for supicions to emerge.

Bitpay's Copay wallet used the even-stream library, and Bitpay was not involved in raising the alarm over this grave subversion of their product.

Manufactured TrannyCoCist Outrage Over SQLite's Longstanding Benedictine Code Of Conduct As CoC Incompatibilities Set Up To Replace License Incompatibilities As Top Open Source Drama Fountain

Yesterday left wing social engineers unleashed a wave of manufactered outrage over the SQLite project's 8 month old adoption of The Rules Of Saint Benedict in the face of demands by unspecified clients to have a Code of Conduct, any Code of Conduct at all. SQLite author D. Richard Hipp offered the following statements in response to questions on why he didn't edit down the list to a more minimalist, TrannyCoCist compatible form:

I could have edited the list down to just those aspects that seem relevant to coding, but that would put me in the position of editing and redacting Benedict of Nursia, as if I were wiser than he. And I considered that. But in the end, I thought it better to include the whole thing without change. In the preface, I tried to make clear that the introspective aspects could be safely glossed over.

Nobody is excluded from the SQLite community due to biological category or religious creed. The preface to the CoC should make this clear. The only way to get kicked out of the SQLite community is by shouting, flaming, and disrespectful behavior. In 18 years, only one person has ever been banned from the mailing list.

It remains to be seen how many Open Source projects which have bought into full TrannyCoCism will find themselves so deficient in love and humility that they believe the words of Benedict of Nursia ought to be censored, rejected, and abandoned.

Semiconductor Fabricator TMSC Struck By Virus On Production Equipment

Semiconductor Fabricator TMSC annouced that they were hit with a virus that multiple pieces of their production operation in Taiwan. TMSC alleges the virus entered their systems as they were installing software for a new tool. TMSC's full announcement:

Issued by: TSMC
Issued on: 2018/08/05
Hsinchu, Taiwan, R.O.C., Aug 5, 2018 – TSMC today provided an update on the Company’s computer virus outbreak on the evening of August 3, which affected a number of computer systems and fab tools in Taiwan. The degree of infection varied by fab. TSMC contained the problem and found a solution. As of 14:00 Taiwan time, about 80% of the company’s impacted tools have been recovered, and the Company expects full recovery on August 6.
TSMC expects this incident to cause shipment delays and additional costs. We estimate the impact to third quarter revenue to be about three percent, and impact to gross margin to be about one percentage point. The Company is confident shipments delayed in third quarter will be recovered in the fourth quarter 2018, and maintains its forecast of high single-digit revenue growth for 2018 in U.S. dollars given on July 19, 2018.

Most of TSMC’s customers have been notified of this event, and the Company is working closely with customers on their wafer delivery schedule. The details will be communicated with each customer individually over the next few days.

This virus outbreak occurred due to misoperation during the software installation process for a new tool, which caused a virus to spread once the tool was connected to the Company’s computer network. Data integrity and confidential information was not compromised. TSMC has taken actions to close this security gap and further strengthen security measures.

S/MIME And Poor OpenPGP Email Client Behavior Leak Plaintext

Today disclosure of two plaintext leaking behaviors in email clients handling OpenPGP and S/MIME encrypted messages has been released (archived). The vulnerability affecting S/MIME is baked into the S/MIME standard and may only be mitigated by abandoning S/MIME, no other mitigation is possible. Meanwhile the plaintext leaking behavior affecting OpenPGP encrypted emails requires certain common but very stupid behavior on the part of an email client and the user allowing the email client to be involved in decrypting the message.

The attack in OpenPGP encrypted email involves the message being molested on the wire in such a way the plaintext metadata surrounding the cyphertext is modified to engage your typical email client's HTML rendering engine. If the email client is allowed to be involved in decrypting the cyphertext as is common with various client "plugins", the email client can "phone home" the plaintext after decryption to the message's molester according to the spurious instructions delivered to the HTML rendering engine. The mitigation for this vulnerability is hygiene and not allowing your email client to be involved in cryptographic operations beyond sending and recieving cyphertext blobs encrypted and decrypted elsewhere.