Tears of the Phucked.

Grumman Hellcat.

Grumman Hellcat.

Phuctor – rewritten and revved up on new hardware in April – is presently eating SSH RSA keys from a scan of the complete IPv4 space.

And, on occasion, breaking some.

And generating other laughs as well.  In today’s server logs: - - [22/Jul/2016:15:54:57 +0000] "GET /gpgkey/50840391E5677882196999C9AE77F3177E6CBF8D35FB4F1FEF848CFADF9088B1 HTTP/1.1" 200 3425 " "

What’s that? A ‘Websense’ censortron control panel, apparently.

Who might it belong to ? Could it be:

Isn’t it just a little bit too late for this nonsense? Plus, your monkemployees can still read the page when they clock out and go home. Or on their phones, in the toilets, etc.  Why bother with this nonsense ? Phuctor isn’t even a ‘wikileak’ or the like, it is merely one of the public whipping posts to which you have been tied, by your own hands, long ago.

Terraforming the “MyCloud Mini” : TTY.

“MyCloud Mini” is a ~$50, dual-core ARM, 256M RAM, 256M Flash, dual SATA box, in various respects similar to the famous PogoPlug.

Use a standard (e.g., CP1202) TTL converter. And you will get:

Stage-1 Bootloader    1  28 10:36:29 CST 2011
Attempting to set PLLA to 750MHz ...
  plla_ctrl0 : 0x0000000A
  plla_ctrl1 : 0x000F0000
  plla_ctrl2 : 0x001D01A0
  plla_ctrl3 : 0x00000017
Setup memory, testing, Image 0
  Hdr len: 0x0001AC3C
  Hdr CRC: 0xB931AD17
U-Boot 1.1.2 (Oct 28 2011 - 10:44:29)
U-Boot code: 60D00000 -> 60D1AC3C  BSS: -> 60D1F2F4
RAM Configuration:
        Bank #0: 60000000 256 MB
SRAM Configuration:
        64KB at 0x50000000
NAND:256 MiB
*** Warning - bad CRC, using default environment
In:    serial
Out:   serial
Err:   serial
Setting Linux mem= boot arg value
Reading upgrade flag from NAND address 0x01ec0000 : 0
Hit any key to stop autoboot:  0
Posted in: Bitcoin, Cold Air, Hardware, NonLoper by Stanislav 2 Comments

Phuctor is Back!

Phuctor is back!

Now using Bernstein’s Algorithm (D. J. Bernstein. How to find smooth parts of integers.) The entire set is pairwise-GCD’d hourly.

Vectored Signatures, or the Elements of a Possible V-Algebra.

Once upon a time (in August of ‘15, to be exact) I wrote a very simple versionatron called ‘V‘.

Edit: See also Ben Vulpes’s excellent introduction to V.

V is a carefully-designed poison against the scurrying little vermin who feed on the proverbial ‘fear, uncertainty, and doubt.’

For readers who are not in the little circle of folks who regularly use the thing, I will outline the – very simple – idea: you diff two texts (source code trees, generic human-readables, or whatever cocktail of the two you happen to have) using a mildly-enhanced GNU Diff, sign the output with your PGP key, and publish it. After this is done, people in your WoT will be able to correctly (in logical order!) apply the patch(-es) – and perform a handful of other useful operations – at their leisure. 1

In exchange for a certain amount of headache – and a willingness to endure a bit of Spartan cruelty – V buys you version control with absolute cryptographic provenance of every delta, fully stateless operation (nothing you do will affect the output of a future operation unless you explicitly move files), a total extermination of the familiar “hidden file” shit-soup placed in directories by, e.g., GIT and SVN, and – most importantly – simplicity, via an absolute minimum of moving parts. V fits-in-head.2

Now this kind of thing is certainly not for everyone. But some thinking folks found it to have interesting implications; others – created some very spiffy applications; yet others – expertly re-implemented ‘V’, to the point where it is almost fit to be thought of as an actual tool.

Half a year later, the thing is in active use by perhaps a dozen people. The one worrisome thing is that most extant V-patches still carry only one known (or, at best, two/three) signatures – seals. Partly this is because people are lazyoverworked. But this is not the whole of it. There is also the fact that the act of producing a V-seal seems to have the connotation of wholesale acceptance, or endorsement, of the payload, and this is quite often The Wrong Thing. Not only are there times when one would like to seal a payload with a caveat of one kind or another, but presently we have no means of conveying disapproval – other than by refraining from sealing. The latter act conveys very little useful information, and no permanent sealed record remains of the effort taken to actually understand the patch. This is a Bad Thing.

One solution that has been floated is the inclusion of human-readable annotations with every seal. And this is well and good, and probably ought to happen, but perhaps it is possible to go a step further!

I would like to seal objects in a way which machine-readably conveys disapproval, doubtful provenance, doubtful veracity, and related attributes. And, naturally this has nowhere to go in classical PGP, and so what I propose here is, for the moment, a mere gedankenexperiment.

The root of the original problem is that a PGP signature per se conveys a scalar – precisely one bit of information: the existence of that signature. But what if it likewise carried a vector ? Can we meaningfully decompose it into orthogonal dimensions ? Let’s say, of four 2-bit components, vaguely inspired by the familiar Unix file access permission scheme:

Dimension 7 6 5 4 3 2 1 0 Meaning
‘Hands’ 0 0 X X X X X X I did not create/modify any part. 3
0 1 X X X X X X I created/modified some part. 4
1 0 X X X X X X I created most, or modified the original beyond recognition. 5
1 1 X X X X X X I claim sole authorship.6
‘Eyes’ X X 0 0 X X X X I read none. Made no attempt to.7
X X 0 1 X X X X I read some part; and/or skimmed some or all.
X X 1 0 X X X X I read most of it.
X X 1 1 X X X X I read all.
‘Brain’ X X X X 0 0 X X I do not understand any.8
X X X X 0 1 X X I understand some, and/or poorly.
X X X X 1 0 X X I understand.
X X X X 1 1 X X I understand absolutely.9
‘Heart’10 X X X X X X 0 0 I distrust absolutely.11
X X X X X X 0 1 I distrust.
X X X X X X 1 0 I trust.12
X X X X X X 1 1 I trust absolutely.13

… adding up to precisely one byte of information conveying belief regarding the payload. This might seem like claptrap until you realize that this seal vector is able to usefully describe a wide variety of objects, of the kind one might seal:

0xCA A sample of output from a particular hardware RNG.
0×78 My dialogue with an NSA agent-provocateur.14
0×01 A One Time Pad found in the pocket of a dead enemy spy.
0×2A A copy of Macbeth.
0×38 A copy of the Donation of Constantine.
0×03 An encrypted message passing through my hands from one close friend to another.
0xDB Your own PGP key.
0×14 A copy of the MS Windows kernel.
0xFF An order to launch the nukes.
0×00 A copy of a suspected memetic bomb.

Listed in no particular order, and not necessarily of the V-tronic variety. Decoding is left as an exercise for the alert reader! To possibly be continued…

  1. Any instance of a V ‘repository’ (there is no distinction between a V ‘repository’ and a working set) consists solely of human-readable texts – in their preferred form for modification: the patches, the keys, and the seals, all of which together can be pressed (the V term for the instantiation operation) into a working copy of the tree, consisting solely of what has been certified by the people whose keys were invoked in the pressing. The dependency order of the patches is automatically respected.
  2. And not merely the source code of V itself – which, in the bulkiest of the extant implementations, weighs in somewhere south of a few hundred lines. The concept fits in one’s head, and can be readily explained in a restaurant over a napkin drawing within one cup of coffee.
  3. Or: “I had no part to play in the item’s having seen the light of day.”
  4. Or: “I had a part in causing the item to exist.”
  5. Or: “The item very certainly would not exist in anything like its present form without my doing.”
  6. Or: “No human hand but mine flipped, to my knowledge, so much as one bit therein.”
  7. Why would anybody sign something they haven’t read? There are many good reasons! E.g., to ascertain that the item existed in its present form when you first came across it, for instance.
  8. This is context-sensitive. The meaning of “understand” is beyond the scope of this article.
  9. Generally this category is to be reserved for items like simple arithmetical facts, or your own name, or any other object about the nature and mechanics of which you have no doubt whatsoever.
  10. This category contains no null. Which should surprise no one, considering that the very intent of a seal is to convey some aspect of trust (in the original, unvectorized pgp, this is a vague and extremely context-sensitive thing, here – a more explicit relationship.)
  11. “I am confident that the object, or the objects referred to therein, contain deliberate misrepresentations of reality, and may be dangerous to your health if perceived as fact, and to your honour – if relayed as factual.”
  12. “I have no cause to believe that a lie is told in the object or objects referred to therein.”
  13. “I trust the factual accuracy of the statement with my life and my honour.”
  14. This leads us into meta/reference problems – does the distrust concern the object itself (the veracity of my copy of the dialogue) or of the statements appearing therein? This is to be resolved by the reader. But would it perhaps make sense to specify this as a whole vector dimension of its own?

Yes, you can still get these.

A package...

A package...


Is it something disreputable...?


... or long-forgotten bars of chocolate ?

A package...

Not exactly.

A package...


A package...


MPI sans the mud.

This README (signed)


Hash: SHA512
What you see here is a very classic version of the GNU MPI (bignum) library.
It has been surgically removed from GnuPG 1.4.10, specifically as found at:
SHA512(gnupg-1.4.10.tar.gz) :
1) Everything pertaining to Automake was nuked, and the earth where it stood -
   Instead, we now have a conventional Makefile. It builds precisely
   ONE THING - a single 'mpi.a' library suitable for static linking into
   another project. This will turn up in 'bin'.
   Among other things, this now means that all KNOBS now reside in a
   MANUALLY-controlled 'config.h' found in 'include'.  If you are building
   on some very peculiar unix, please read it and adjust as appropriate.
   It contains ONLY those knobs which actually pertain to the code.
   The Makefile contains a 'check-syntax' - users of Emacs and Flymake
   will see proper error-highlighting.
2) ALL chip-specific ASM optimizations (including those found in longlong.h)
   have been nuked.
3) GPG-specific cruft has been amputated to the extent practical.
   The logging system has been retained, but it can be easily torn out,
   which I may choose to do in the near future.
   The I/O buffering system has been retained. I may choose to remove it
   in the near future.
   The 'secure memory' (unpageable alloc) system has been retained.
   'Localization' and all related idiocies have been nuked.
   Write hieroglyphs at home, leave them there, civilized folk
   don't need'em in their source code.
4) Other code has been altered solely to the extent required by items
   (1) and (2).
   Cruft which appears in dead #ifdefs may be removed in the future.
   Don't get comfortable with it being there.
5) Readers who wish to know EXACTLY what I changed, should get a copy of the
   original tarball and write a simple script involving 'find' and 'vdiff',
   which sadly did not fit in the margins of this page.
6) To use the library, include 'include/mpi.h' in your project,
   and statically link with 'bin/mpi.a'.
7) The original code was distributed under GPL 3, which may apply on
   your planet and is therefore included. (See COPYING.)
Version: GnuPG v1.4.10 (GNU/Linux)

You will need the V versionatron to use the ‘v-genesis’.


  1. Item (4) should read ‘(1), (2), and (3)‘ instead of ‘(1) and (2)‘.
  2. Users of modern Gnu GMP might expect a cryptographic entropy generator.  This MPI does not contain one – it was a separate subsystem. At some point I may do a similar surgical extraction for GPG 1.4.10’s entropy gatherer, but this is a very different project.

The Phuctored and the Phucked

(8/16 Update: 113 moduli.)

Phuctor has been under lightweight but rather reliable DDOS in recent times, so here is a mirror of the list of 106 moduli broken up through the time of this writing.

Certain professional idiots have been bashing their heads against the wall in a futile effort to magic away the past.  To them, my message is:

  1. It won’t work.
  2. Go to hell.
  3. The data set is in permanent public record.  Go ahead, keep censoring SKS mirrors.  We still have the originals.
  4. We will discover who planted the diddled keys, when, and why.

If your name appears on the list (or the current version thereof), please write to Mircea Popescu or to me! (Please keep in mind that letters not bearing a PGP signature – the basic minimal standard for personhood on the Net – are likely to be ignored – or, alternatively, subjected to public display and ridicule for our amusement.)

Phuctor Broke Several RSA Keys.

(5/20 Update: This.)

(5/18 Update: Tired of the contemptible media disinformation and faux-reporting on this subject? For some fresh air, see Mircea’s article, ‘On how the factored 4096 RSA keys story was handled, and what it means to you.’)

Phuctor, “The RSA Supercollider,” is a long-term collaborative project of yours truly and Mircea Popescu.

I am pleased to announce that we have now broken a 4096-bit RSA key, as well as its factor-sharing counterpart (yet to be determined, but won’t wait for long!)

At five minutes prior to the time of this writing, another pair of keys has also been broken.  See Mircea’s site for updates.

Readers who wish to learn more about this project are invited to join Mircea, myself, and many other fine folks on Freenode in IRC channel #bitcoin-assets. Click here for a WWW-based gateway. Politely privmessage an “up please” to one of the regulars to get speaking rights.

Edits, Corrections:
1 ) Threads on Reddit, Hacker News. (5/18: If you care to read these, do it while they’re still up.)
2 ) Selected hate mail. Will update this section if any more contenders for this list should appear.
3 ) May 17 ~16:10 EST: Aaand we got another! A GNU developer, like the first. Which makes for six phuctorable keys, three of which are presently known to me.
4 ) Before joining the chorus of ‘Holy shit, they broke RSA!’ or ‘This is false advertising, they didn’t really do anything!’ imbeciles, please consider reading the (one whole page!) description of what Phuctor actually does.
5 ) If you are in the service of the enemy, and think that you can somehow prevent or retard the search for weak (weak for whatever reason! I don’t weaken them, only search…) fielded RSA keys, think again. The data set is public in its entirety, and the experiment can be replicated by a schoolboy with minimal sweat. Go ahead and remove the diddled keys from public servers, if you like. We have copies.
6 ) This is addressed to the same fine folks as #5. Your efforts to bury the story in FUD and hastily-concocted disinformation are riotously funny. Please carry on.
7 ) Consider getting your tech news from journalists who can spell. (Seriously, ‘Phunctor’ ?!)
8 ) (5/18) We found a number of moduli, including several pairs which share a large composite factor.  Stay tuned.
9 ) Folks who believe that ‘anyone can insert anything into SKS‘ are invited to replace my key there with their own.
10 ) (5/19) As of today, there are 10 broken moduli.

Practical Blockchain Telegraphy.

Mircea Popescu writes:

‘Now making an irc channel is quite the pleasant experience : you create something out of nothing, get to name it and are now the boss of it. For a generation devoid of proper “empire building” avenues, this is about as cool as it gets. So you can do anything you wish, right ? Your channel, your rules, that’s the deal! … But all is perhaps not quite right in this world. Driven by a deep seated intuition that perhaps no, perhaps this isn’t the deal, perhaps the whole charade’s an illusion, the kids in question move compulsively to test it. So they dump child porn or stolen bank credentials or whatever it is that’s taboo in the larger society they fear they might have failed to individuate from. … So how did the story end ? Why, with the Freenode admin pointing out that no, you can’t ban Freenode admins from your Freenode channel. Because while it is “yours”, it is nevertheless… a Freenode channel. And so the adventure came to an end, the kids weren’t interested in wasting time with the rotten foundation of pretend-ownership, and pretend-control and pretend-alodial, and Freenode wasn’t interested in wasting time with some users that were inclined to verify the limits of “your” and “yours”.’

At this point, the tale is familiar – in one form or another – to nearly everyone with an Internet connection. But, as Mr. P points out, we are now reasonably well-equipped to change the story’s ending:

‘So yes, because Bitcoin now I can have, if I feel like it, an irc network that works exactly the way those kids’ didn’t, a decade ago. They had no choice but to go home and cry about it, about their failure, about their dashed dreams and hopes, yet guess what : I do.’

The exact mechanics of this hypothetical network were left as ‘an exercise for the alert reader.’ Let’s explore one possible solution to the exercise!

What follows is perhaps the most obvious conceivable recipe using the ingredients at hand. The ’server’ and each ‘client’ need only a standard copy of ‘bitcoind.’ The clients – at least initially – will each need a certain amount of Bitcoin.

First, the engineering envelope – the smallest and largest useful transaction for this blockchain abuse.

Let’s start with the lower bound. Bitcoin transactions containing outputs of less than 0.01 are discouraged by the network (miners demand extra ‘fee’ to incorporate such a transaction into a block.) Hence all outputs must exceed the ‘dust constant.’

As for the upper bound: the Bitcoin protocol gives us 8 bytes for a transaction amount (in units of satoshi, 1×10^-8 BTC.) However, we cannot use all eight bytes for payload – unless the channel is to be inhabited solely by royalty.

So let’s pick an ‘amplitude’ range: an amount of 0.01001 to 0.01256 BTC for each individual byte of the payload.

But now we are faced with the fact that a Bitcoin transaction will only be incorporated into the blockchain in a timely manner if a ‘miner’s fee’ (traditionally, 0.01 or so) is included. So we do not want one transaction per byte of payload. Hence, an engineering compromise is suggested:

The ’server’ creates a ‘channel’ by generating a certain number (let’s say 32, but this is not a critical constant) of Bitcoin addresses (public/private key pairs) - A1A2, … AN.

Server and client alike decode messages by examining the Bitcoin blockchain and parsing out amounts sent to these addresses. No use is made of ‘exotica’ – i.e. human-readable fields of the Bitcoin transaction, and other ‘garbage’ that might conceivably end up pruned from the blockchain in the future.

The only distinction between the server and the clients is that the server is the fellow who has the private keys to the address array. The one and only responsibility of the server is to re-send the coins back to the originators (selectively! see below.)

What ideal value of N to pick for AN? This is left as an exercise for the alert reader. Consider that miner’s fees increase with ‘mass’.

A client may speak on the channel by emitting a transaction of the following form:

bitcoind sendmany “” ‘{”A1″:0.01256,”A2″:0.01256,”A3″:0.01256}’

This transmits the string 0xFFFFFF. If a string longer than N is to be transmitted, the address index must simply loop around. So, if we wish to ’speak’ the ascii string ‘foobar’:

bitcoind sendmany “” ‘{”A1″:0.01103,”A2″:0.01112,”A3″:0.01112}’

bitcoind sendmany “” ‘{”A1″:0.01099,”A2″:0.01098,”A3″:0.01115}’

Two transactions. If we assume a miner’s fee of 0.01 BTC included with each, the total cost of transmission is 0.08639 BTC (about $50 USD in today’s exchange rate.) Yes, 19th century ‘Western Union’ telegraph looks like a bargain by comparison. But see below.

We can easily anticipate the objection: “No one would speak on this telegraph – they would soon go broke.”

The answer: the channel operator would return the coin to the originating address. Not immediately, of course (minimizing transaction fees.) And, naturally, not to everyone – merely those who are welcome guests in the channel. Unwelcome guests (spammers, and bozos of any and all other species) will find that they have stumbled into a ruinously expensive waste of time – because they will never see their coin again. (What to do with the ‘bozo coin’ is for the operator to decide. He can buy beer with it, pay for his bandwidth, or parcel it out to the welcome guests – whatever pleases him.)

Thus, we have an automatic moderation mechanism. Likewise, we get cryptographically-strong identity ‘for free’ – originating addresses of the transactions become user identities (they can be matched with human-readable names in some agreed-upon fashion, e.g. using a magic ‘hello’ packet.) We likewise get a ‘free’ perpetual log of the channel conversations.

If the system is run as a closed loop, the only ultimate cost to the operator and clients is the accumulated miner’s fees – which can be minimized by choosing a large N for the address array, and by returning the coins to their originators in infrequent (e.g. weekly) parcels.

The mechanics of this ‘chat’ apparatus will encourage brevity – and perhaps, clarity of thought. Or, alternatively, it could easily degenerate into a kind of mournful ‘twitter.’ Only one way to find out…

One obvious criticism – ’slow.’ Sure, we can wait eight minutes for a confirmed transaction. Or we can parse immediately. Depends on one’s taste.

Tungsten Will Melt in Your Mouth!

But, of course – it won’t.

But let’s imagine that it were in someone’s financial – hell, geopolitical! interest – to convince the public that it will. The New York Times editorial might go like this: ‘you may have heard of tungsten, a metal, just like gallium; the latter, a favourite among stage magicians for melting at body temperature…’

Now, it is possible that accounts of luscious, easily-melted tungsten have yet to be printed in your friendly local fishwrapper merely on account of there being no one who wishes to pay for communicating this ‘fact’ to us. But I can’t help but suppose that there are other forces at work here.

Consider, for instance, the equally-factual statements Bitcoin can be counterfeited at will and has no use value’ – or ‘being pwned is an inevitable fact of life’, or…

Somewhere between ‘tungsten melts in your mouth’ and the above ‘facts,’ there lies a kind of boundary. A line which professional liars cross at their peril. If there is an accepted, traditional term for this, I should like to learn it.