Le Ping
Ze Pong
Re: ping - Karl
Stefan, I was looking through my history a little and wanted to apologize for criticizing and devaluing your valuable work. This seems to be a psychological issue I [still] strongly have.
Re: Re: ping - Karl
> an anti-imperialistic Operating System, for > home usage, e.g. Linux No, Linux calls for nasty imperialist governments and their courts and apparatus to brutally enforce their socialist "GPL" "copyright" "license" under threat of death. Minimal Berne copyrights don't force anyone to do anything, that is the much better voluntary way of actual freedom... https://www.openbsd.org/policy.html https://cvsweb.openbsd.org/src/share/misc/license.template?rev=HEAD https://cgit.freebsd.org/src/tree/COPYRIGHT
Re: Re: Re: Re: Re: ping - Karl
On 2/19/22, Stefan Claas wrote: > Thanks, > > I wanted to present a way for people within the EU > to have an option to phase out the old and non > reliable and non trustworthy WoT, which can't, as > you know, not been used for businesses, contracts etc. It's great you guys are mainstreaming cryptography. I hope it is true. It was too helter-skelter when WoT was phasing away for me to understand any good reason for it to happen. Both our countries were targeted by a psyop business during that. > > The blockchain stuff I did only mostly for Americans, > because they like NFTs and stuff like that. Most americans are govcorp sheep like my psychosis wants me to be, just like in other countries. > > Please feel free to forge the certificate or blockchain > proofs so that we can brainstorm about better ways to > secure certain things digitally. I visited the website but didn't see a quick-and-easy-to-find avenue for independent verification, such as a concise merkle tree spec. Anyway it comes down to trusting the private company attesting to you either way, since they propose using their website to check. Hopefully they offer something better than SSL to do that via.
Re: Re: Re: Re: ping - Karl
anyway like, clearly you have more experience with cryptography than me, i should probably consider you a good person to have the public key of
Re: Re: Re: Re: ping - Karl
On 2/19/22, Stefan Claas wrote: > The reason why I did it this way with a certificate: > > To have a *proof* of ownership and option that it > is me who did that and the blockchain helps to > undermine that, because at the timestamping service > I am registered and log in there via Gmail. > > My pub key in the certified document is stored > on a YubiKey for additional security and can be > uses with rage, the Rust version of age, because > age currently does not have this option. > > Two other things about my certificate. > > The identicon graphic represents a visual representation > of my public key ASCII string and the QR-Code contains > a Hashcash token, created from my pub key and De-Mail > adress. > > Regards > Stefan It is so wonderful you did these things. But what is the point of the putting timestamps on the blockchain in a way that can be forged on-chain manually?
Re: Re: Re: ping - Karl
On 2/19/22, Stefan Claas wrote: > Hi Karl, > > the certified document's hash is in three blockchains, > Bitcoin, ETH and Aion, which you can easily verify. > And I did not payed any cent for the transactions. > > Regards > Stefan But why not use a direct document hash that can be verified if you lose your proof document, on chains with dust transaction fees, or in a cooperative of hackers who demonstrate better protection of your data than that?
Re: Re: ping - Karl
> forgot to mention, > > IIRC when you upload my document the timestamp of my original > document stays the same and re-upload with a new timestamp is > not possible. Please sign up with the service to try out, you > have 5 free timestamps per month and don't have to use their > payed plan. Are you aware that you can publish a merkle hash to a blockchain whenever you want for only the transaction cost of doing so?
Re: Re: ping - Karl
Cryptographically I imagine there's a lot of space of different guarantees here. I'm mostly just still sticking out for the missing point in the service that was mentioned earlier. I'm big on detering erasure of history, which the present service provides for.
Re: Re: ping - Karl
On 2/19/22, Stefan Claas wrote: > Hi Karl, > > if you click on the certificate URL (Online Verrification) > and upload the certificate to the URL, you will see that > it is signed by an EU Trust Service Provider, for the eIDAS > regulation within the EU. This signature is legally binding, > and is equal to a handwritten signature on paper, for contracts, > businesses etc. and can be verified globally, even if countries > outside the EU have no eIDAS. Can be also verified with the free I don't dispute this, aside from whether laws would influence anybody likely to be able to make use of forging something like that, which we've already made indirectly clear we have different values around. > Adobe DC Reader. Adittionally, as you have seen, I have then > uploaded the certificate to the time stamping service, to include > the hash of the certificate into blockchains. This is what I'm worried about. Is this the same timestamping service that was earlier shared on this list? I reviewed it and found it does not actually store the hash on the blockchain. It instead stores a hash in the document, that can be used with a hash on the blockchain. This means if somebody infiltrates your government and does the same thing, the blockchain relies on you (a) retaining your document and (b) getting your document to anybody who checks the fake document, when they do the checking, to offer you any guarantees. If instead the actual hash of the document were on the blockchain, it would be easy to check what was original, without you needing to self-preserve and self-advocate.
Re: ping - Karl
Stefan, thanks for your inspirational transparency. Hopefully we can migrate somehow to protocols that show that documents are the first ones published of their kind, rather than just that they were published at the time they say they were. Is this something you can mention to originstamp? If I can destroy your document and republish one of my own, I can pretend to be you, because the public hash is rehashed by the document hash in the protocol.
Re: [tor-dev] Relay "Ping" Functionality
Well onioncat is not "arbitrary node" but is a set up one. Yet some timing differentiations can be divined by selectively constructing the "circuit" to test, looking at setup timings, pushing characterizing traffic through them and your own nodes, polling existing services, etc. Please publish your results.
Re: [tor-dev] Relay "Ping" Functionality
> Right now we're exploring latency-based attacks but are having trouble > achieving a particular goal: a way to “ping” an arbitrary node in a > client’s already-built (“live”) circuit. One-way timing is ideal but round > trip time would suffice. We can glean this information during circuit > construction, but what about a “live” circuit? Ideally, this would be a > periodic thing Tor already keeps track of, but as an on-demand or as a > byproduct/side-effect of a different function would also work. We have not > been able to find a way to do this within the Tor (sub)protocol specs or > the control port spec. Use OnionCat and ping6, it is exactly what you want. https://www.onioncat.org/ Such "timing" attacks are in the scope of "Tor Stinks -- NSA" document. Users should become familiar with them, and that slide deck, and other attacks from over a decade ago. And with how tor does not address them.
Re: ping
I just noticed that now I started receiving Emails directly from the list here on gmail.com. Issue solved. Hi friend Mirimir : ) Em sex., 19 de jun. de 2020 às 17:10, Mirimir escreveu: > On 06/19/2020 12:46 AM, Georgi Guninski wrote: > > Do you read me? > > > > What a debugging drama, anyone has a conspiracy theory ;) ? > > I got this directly from Gmail, and did not get a copy via the > cypherpunks list. > -- Regards GTI
Re: ping
On 06/19/2020 12:46 AM, Georgi Guninski wrote: > Do you read me? > > What a debugging drama, anyone has a conspiracy theory ;) ? I got this directly from Gmail, and did not get a copy via the cypherpunks list.
Re: ping
Possibly useful advice for @gmail users below, also some list diagnostics: On Thu, Jun 18, 2020 at 03:20:50PM -0700, Mirimir wrote: > On 06/18/2020 02:29 PM, Se7en wrote: > > On 20-06-18 14:23:02, Mirimir wrote: > >> Thanks. I wasn't paying attention, but I did notice the warning about my > >> list membership being disabled: > >> > >>> Your membership in the mailing list cypherpunks has been disabled due > >>> to excessive bounces > >> > >> I'm not sure whether that was a cypherpunks server issue, or a Riseup > >> issue, which was perhaps triggered by a cypherpunks server issue. > > > > The list admin published a few days ago that the list was experiencing > > trouble and has been rectified. You must not have recieved that > > message. Check the public archive. > > Looking in the public archive, the first hint of a problem was Georgi > Guninski's "pong" and Greg Newby's reply at Jun 15 05:25:59 PDT 2020: > > https://lists.cpunks.org/pipermail/cypherpunks/2020-June/081025.html > https://lists.cpunks.org/pipermail/cypherpunks/2020-June/081026.html > > Then there's the message from Greg at Jun 16 19:39:50 PDT 2020, saying > that the "the list was bouncing all day today (after around 9am US > Eastern Daylight Time)" and that "[t]hings now seem to be fixed": > > https://lists.cpunks.org/pipermail/cypherpunks/2020-June/081030.html That was a temporary 13-hour problem caused by a specific misconfiguration I applied. There is no indication that mail delivery problems before that are related. > But GTI.H and Georgi Guninski both reported on Jun 17 that they still > weren't getting list messages to Gmail accounts: > > https://lists.cpunks.org/pipermail/cypherpunks/2020-June/081042.html > https://lists.cpunks.org/pipermail/cypherpunks/2020-June/081043.html > > I got the last message before today at Jun 14 14:38:29 PDT 2020: > > https://lists.cpunks.org/pipermail/cypherpunks/2020-June/081016.html > > I got the membership disabled message at 18 Jun 2020 00:15:00 -0700, and > it said: > > > Your membership in the mailing list cypherpunks has been disabled due > to excessive bounces The last bounce received from you was dated > 18-Jun-2020. You will not get any more messages from this list until > you re-enable your membership. You will receive 2 more reminders like > this before your membership in the list is deleted. > > That is, messages to me were bouncing from late Jun 14 through Jun 17. There were a ton of bounces from @riseup.net (there are several subscribers, not only you). I suspect that this WAS due to the misconfiguration I did, but I didn't save the 450+ bounce notifications. You should be able to reenable your subscription as directed... let me know if you run into trouble. > Anyway, it's not a big deal. I'm just curious whether bouncing started > earlier, perhaps on Jun 14, and why Google and Riseup kept bouncing > messages after Greg fixed the cypherpunks server. Here's the important part (saved for the end): For @gmail.com users, I experimented by subscribing a gmail address to the list. I found that MOST (not quite all) messages were flagged as spam and therefore did not arrive in my inbox. I flagged as "not spam" to extract them from the spam folder, which might train gmail. But the approach I suggest is to create a filter in gmail. This is easy in the Web interface, but I don't know about other clients. Simply make a filter so that messages with "list:(cypherpunks.lists.cpunks.org)" or to/cc cypherpunks@lists.cpunks.org are never flagged as spam. - Greg
Re: ping
On Fri, Jun 19, 2020 at 4:14 PM Greg Newby wrote: > > That was a temporary 13-hour problem caused by a specific misconfiguration I > applied. There is no indication that mail delivery problems before that are > related. > I definitely had gmail problems for at least 3 days and I check spam several times per day.
Re: ping
Do you read me? What a debugging drama, anyone has a conspiracy theory ;) ?
Re: ping
On 06/18/2020 02:29 PM, Se7en wrote: > On 20-06-18 14:23:02, Mirimir wrote: >> Thanks. I wasn't paying attention, but I did notice the warning about my >> list membership being disabled: >> >>> Your membership in the mailing list cypherpunks has been disabled due >>> to excessive bounces >> >> I'm not sure whether that was a cypherpunks server issue, or a Riseup >> issue, which was perhaps triggered by a cypherpunks server issue. > > The list admin published a few days ago that the list was experiencing > trouble and has been rectified. You must not have recieved that > message. Check the public archive. Looking in the public archive, the first hint of a problem was Georgi Guninski's "pong" and Greg Newby's reply at Jun 15 05:25:59 PDT 2020: https://lists.cpunks.org/pipermail/cypherpunks/2020-June/081025.html https://lists.cpunks.org/pipermail/cypherpunks/2020-June/081026.html Then there's the message from Greg at Jun 16 19:39:50 PDT 2020, saying that the "the list was bouncing all day today (after around 9am US Eastern Daylight Time)" and that "[t]hings now seem to be fixed": https://lists.cpunks.org/pipermail/cypherpunks/2020-June/081030.html But GTI.H and Georgi Guninski both reported on Jun 17 that they still weren't getting list messages to Gmail accounts: https://lists.cpunks.org/pipermail/cypherpunks/2020-June/081042.html https://lists.cpunks.org/pipermail/cypherpunks/2020-June/081043.html I got the last message before today at Jun 14 14:38:29 PDT 2020: https://lists.cpunks.org/pipermail/cypherpunks/2020-June/081016.html I got the membership disabled message at 18 Jun 2020 00:15:00 -0700, and it said: > Your membership in the mailing list cypherpunks has been disabled due to excessive bounces The last bounce received from you was dated 18-Jun-2020. You will not get any more messages from this list until you re-enable your membership. You will receive 2 more reminders like this before your membership in the list is deleted. That is, messages to me were bouncing from late Jun 14 through Jun 17. Anyway, it's not a big deal. I'm just curious whether bouncing started earlier, perhaps on Jun 14, and why Google and Riseup kept bouncing messages after Greg fixed the cypherpunks server.
Re: ping
On 20-06-18 14:23:02, Mirimir wrote: > Thanks. I wasn't paying attention, but I did notice the warning about my > list membership being disabled: > >> Your membership in the mailing list cypherpunks has been disabled due >> to excessive bounces > > I'm not sure whether that was a cypherpunks server issue, or a Riseup > issue, which was perhaps triggered by a cypherpunks server issue. The list admin published a few days ago that the list was experiencing trouble and has been rectified. You must not have recieved that message. Check the public archive. -- |-/ | Se7en / The One and Only! | se7en@cock.email / | 0x0F83F93882CF6116 / | https://se7en-site.neocities.org
Re: ping
On 06/18/2020 01:04 PM, Sangy wrote: > Yes > On Thu, Jun 18, 2020 at 12:55:21PM -0700, Mirimir wrote: >> Is this thing on? Thanks. I wasn't paying attention, but I did notice the warning about my list membership being disabled: > Your membership in the mailing list cypherpunks has been disabled due to excessive bounces I'm not sure whether that was a cypherpunks server issue, or a Riseup issue, which was perhaps triggered by a cypherpunks server issue. A postmortem would be cool.
Re: ping
Yes On Thu, Jun 18, 2020 at 12:55:21PM -0700, Mirimir wrote: > Is this thing on?
ping
Is this thing on?
Re: high latency low b/w ping circles: random vs clocked
On Sun, Oct 27, 2019 at 01:51:36PM +1100, Zenaan Harkness wrote: > > If the ping is not clocked, but is timed (clocked) to a statistically > > random time within a configured window, the GPA cannot know when to > > conduct their latency injection attack, and any dropout by me, would > > be seen by those who failed to receive my ping or received a delayed > > ping, as nothing but white noise, since every ping is randomly timed > > anyway. > > > The ability to hide ping recipients when I and or they are only > intermittently connected (i.e., we all live on mobile phones), is in > serious doubt. > > The reasonable (excepting further analysis) operating mode is to, at > least, have a node which is permanently connected - but again, we > need consider each use case in due course... That said, friends expose their friend connections daily these days - sms, text, phone calls, facebook, "likes" and endless more social virtue signalling signals. "You and your friends, who live only on mobile phones" are often connected around the same time. In these circumstances, fixed base rate links provide hiding of whether or not we are chatting, voice talking, or surfing through one another's nodes. This is useful "content, and type of" comms hiding. "Just because we cannot hide who we are communicating with, does not mean we should not exercise our right to hide the content and frequency of our communications." If my phone always connects to the same peer nodes when I turn my phone on, and vice versa, and we always establish certain base rate links, we may not even be communicating and no one would know, assuming we always reserve a minimum base rate load as "chaff or wheat" between our phones, and such that when we accept additional circuit requests, those exist above the private "always reserved" base link. This is the headroom concept, but always chaff filled, and reserved between me and my primary first hop peers.
Re: high latency low b/w ping circles: random vs clocked
high latency ping circle pings, should effectively disappear in the
"usual mix" of traffic between standard peers.
1-hr +/- 15 minutes ping circle with immediate peer nodes ("friend")
could be a mandatory base load.
Even just coordinating links between peer nodes is an order of
magnitude greater b/w - the pings "as wheat" will disappear "in the
chaff of normal net/switch coord traffic", and automatically provide
for high-value and hidden (to onlookers) text messages to be sent
around.
Imagining a UI element:
HiddenMessageService
- send message to friend
- choose latency:
- "std (up to 1.5 hrs to arrive)"
- "half hour max"
- "1 minute max"
- "10 seconds max"
- I type text and choose "1 minute max option"
- app pops up saying "Enable 1 minute max messages to friend
Blah, this will incur up to a 12MiB per month b/w overhead"
- I click yes.
- the app negotiates such a link with my friend
- every time we are both connected, we maintain this link
- until we optionally disable that link
- because peer nodes must negotiate and regularly communicate re
switching and routes and b/w, in order to anything at all,
the overhead of that "1 minute max" link might almost disappear
completely into regular network control packets (remember, we
combine packets up to MTU or "configged normalized packet size"
anyway, and we reserve the required b/w for such control packets
as well - always keep a little headroom
- i.e. that 12MiB/month might end up being much closer to the
marginal size of the actual text messages only.
Re: high latency low b/w ping circles: random vs clocked
On Sun, Oct 27, 2019 at 01:15:56PM +1100, Zenaan Harkness wrote: > Here's an obvious in hindsight thought: > > Use case: A (hidden, encrypted etc) ping circle (some combo of star > or token ring yet to be designed) amongst a group of friends who may > at random points in time, wish to send wheat txt sms in the chaff of > the regular circle ping. > > Usually the ping is chaff. > > Any particular ping can be wheat (an sms/txt/email). > > If the ping is clocked, and there is any leakage of the clocking, > then a GPA jamming my ISP link for say 5 seconds, right at the time > I'm about to send my regular ping, would expose the other node(s) I > am pinging. Even the above statement is not necessarily true, may be not true at all: So I ping my 1st hop peer set, who have also these fixed low b/w ping links to their peers, etc, and some subset of all these are part of my ping circle of trusted friends. The earlier postulate (see OP email below) holds, namely that: "The b/w of the ping is so low, that there is little to incentive to not maintain such (virtual) links, even if an incoming ping fails to arrive; and the value of such hidden communications is far greater (and the anonymity of your circle), and so there is abundant incentive to maintain such low-cost links." So, even in the case of a clocked ping, the targets of my low b/w high latency ping are perhaps unlikely to be exposed, using active latency injection attacks. Notwithstanding this fact, the high latency nature of such ping circles suggests that statistically random clocking --within a specified window-- (e.g. 1hr ping, +/- 15 minutes window), would presumably not detract from the security of such links, and may well mitigate unforeseen future attacks. With a shout out to the pipe-net punks and others from ~1995. https://en.wikipedia.org/wiki/David_Chaum https://en.wikipedia.org/wiki/Mix_network > If the ping is not clocked, but is timed (clocked) to a statistically > random time within a configured window, the GPA cannot know when to > conduct their latency injection attack, and any dropout by me, would > be seen by those who failed to receive my ping or received a delayed > ping, as nothing but white noise, since every ping is randomly timed > anyway. The ability to hide ping recipients when I and or they are only intermittently connected (i.e., we all live on mobile phones), is in serious doubt. The reasonable (excepting further analysis) operating mode is to, at least, have a node which is permanently connected - but again, we need consider each use case in due course... > [To state what ought be obvious, the pings, though high priority when > they are sent at extreme high (compared to normal web traffic) > latency intervals, are still sent through 'regular' chaff-filled > links, and so except for my local links temporarily dropping out, a > GPA stalker should not be able to determine destination nodes for my > ping, with any latency injection attack. There is an unnamed assumption in the above - my ping circle includes only known friends. If my ping circle includes unknown destination nodes, detecting network dropout is trivial (I only have to be actively taken offline for a duration longer than the ping interval (+rand window), for the target to identify me. "Don't talk to strangers about highly important things." "Know your peer." "High value communications (and therefore network links/ routes) with unknown peers, exposes you to active stalker (e.g. government) attacks." > The reasons we can make such an assertion and believe this holds > true: > > - active latency injection attacks operate on the principle of > statistically modifying the distribution of packets across a > route (in time (for latency) or some other metric e.g. size) > > - in the case of extremely high latency packets (say, 1 hour > between packets) at least when sent between nodes trusting one > another or via nodes which, if they introduce a few seconds or > minutes of latency, cannot meaningfully impact the ping, the > relevant statistical "distribution of packets across time" is in > the order of (in this example) hours > > - the b/w consumed by such ping circles very low > - those in my ping circle, have little incentive to close such > low b/w "chaff filled links" on the outgoing side > - and in fact, those who want to see freedom of anonymous speech, > will actively support such links (again, due to their low > network costs) > - and so those nodes which do NOT maintain such links when > requested, naturally increase their stalker score (as viewed by > others). > ] > > > "Treat each use case for its unique snowflake characteristics, >and we provide for the possibility to optimize that particular >use case." >
high latency low b/w ping circles: random vs clocked
Here's an obvious in hindsight thought: Use case: A (hidden, encrypted etc) ping circle (some combo of star or token ring yet to be designed) amongst a group of friends who may at random points in time, wish to send wheat txt sms in the chaff of the regular circle ping. Usually the ping is chaff. Any particular ping can be wheat (an sms/txt/email). If the ping is clocked, and there is any leakage of the clocking, then a GPA jamming my ISP link for say 5 seconds, right at the time I'm about to send my regular ping, would expose the other node(s) I am pinging. If the ping is not clocked, but is timed (clocked) to a statistically random time within a configured window, the GPA cannot know when to conduct their latency injection attack, and any dropout by me, would be seen by those who failed to receive my ping or received a delayed ping, as nothing but white noise, since every ping is randomly timed anyway. [To state what ought be obvious, the pings, though high priority when they are sent at extreme high (compared to normal web traffic) latency intervals, are still sent through 'regular' chaff-filled links, and so except for my local links temporarily dropping out, a GPA stalker should not be able to determine destination nodes for my ping, with any latency injection attack. The reasons we can make such an assertion and believe this holds true: - active latency injection attacks operate on the principle of statistically modifying the distribution of packets across a route (in time (for latency) or some other metric e.g. size) - in the case of extremely high latency packets (say, 1 hour between packets) at least when sent between nodes trusting one another or via nodes which, if they introduce a few seconds or minutes of latency, cannot meaningfully impact the ping, the relevant statistical "distribution of packets across time" is in the order of (in this example) hours - the b/w consumed by such ping circles very low - those in my ping circle, have little incentive to close such low b/w "chaff filled links" on the outgoing side - and in fact, those who want to see freedom of anonymous speech, will actively support such links (again, due to their low network costs) - and so those nodes which do NOT maintain such links when requested, naturally increase their stalker score (as viewed by others). ] "Treat each use case for its unique snowflake characteristics, and we provide for the possibility to optimize that particular use case."
