♥ Donate to the Monero Team

https://pepe.expert

https://layerzero.services

https://linktr.ee/layerzeronetwork

https://layerzero.business

Hi,

I am new to crypto and Monero.

When will Kovri be integrated in to the Monero GUI walllet?

Thanks!

Primer:
https://www.youtube.com/watch?v=v_PvLKbeOhs (Good primer!)

​

Meat:

https://devblogs.nvidia.com/dgx-1-fastest-deep-learning-system/ (Hybrid Cube Mesh - DGX 1, good to ~6 GPUs)

https://www.servethehome.com/nvidia-dgx-2-details-at-hot-chips-30/ (I'm guessing Hybrid Fat Tree, good to ~16+ GPUs)

https://export.arxiv.org/abs/1903.04611 ("Evaluating Modern GPU Interconnect: PCIe, NVLink, NV-SLI, NVSwitch and GPUDirect")

https://en.wikipedia.org/wiki/Supercomputer#Distributed_supercomputing (Shows a toroidal-interconnected 3-D cube topology at bottom, similar to some Infiniband networks)

​

Other / Design your own for use in scalable anonymous networks:

https://youtu.be/SisTfH7ns7Y (HPC Networks: Topologies and Design - 2011)

https://youtu.be/pmNpIdtdudg (HPC Cluster Interconnect Topologies - 2014)

https://youtu.be/rLjMrIWHsxs (SlimFly: Cost effective efficient topology - 2015)

https://youtu.be/bXwtQzJVIOY (Innovative Topologies - 2013)

https://youtu.be/DXqhzRhZ2BE (InfiniBand, 3D-Torus topologies, Offloading and accelerations - 2012)

​

Use MFBD or PCID way back from the 90s astronomy club to enhance those low quality posterity videos like the pros (got triggered on the 240p):
http://suvrit.de/papers/icip10.pdf
https://www.researchgate.net/profile/Francis_Flaherty/publication/24398666_Physically_constrained_Fourier_transform_deconvolution_method/links/54c6707b0cf2911c7a58d7e2.pdf?inViewer=true&pdfJsDownload=true&disableCoverPage=true&origin=publication_detail

http://www.filedropper.com/pcidvideoenhancement

It lays out some ideas that helps to significantly reduce forms of traffic analysis where the attacker doesn't have to be participating in the network to see whats going on. The ideas and other methods can be expanded upon to secure the traffic flows against attackers operating inside the network on a majority scale to a decent extent.

​

As a preface, known data of any kind is the enemy. If everyone could have their own privately protected fiber line to every other node that would be almost ideal, but it is not realistic. Eventually even then each line or major junctions of lines would be monitored. That doesn't mean you should give up on privacy and anonymity, which I believe plays an extremely importatnt role in protecting open free speech.

​

Basically this post very generally tries to implement ideas from what I imagine a true mixnet would use. Complete data encryption/obfuscation, full transportation freedom with multi-homing, data aggregation, and raiding/striping. (Don't say homomorphic encryption, don't say homomorphic encryption..)

https://en.wikipedia.org/wiki/Multihoming

https://en.wikipedia.org/wiki/Link_aggregation

https://speedify.com/blog/combining-internet-connections/link-aggregation-router-software/

https://www.connectify.me/blog/wifi-bridge/bridging-vs-bonding-explained/

https://ieeexplore.ieee.org/document/880788

Jun 27 '19: https://youtu.be/rLjMrIWHsxs?t=1349

​

#3 There is no way to connect to other nodes without showing who you are immediately connected to. There are ways around this but no one would casually use it; If it required you to buy expensive hardware and bounce signals off the moon, or an alternate method of communication using Line-of-Sight/Transparent data communications that is of no obvious origin and offering no single redirection point, making it difficult to track but not impossible [EG point-to-point and point-to-multipoint wireless backbone hauls but with terahertz optics].

In reality the best way would be to never have a handshake between nodes and instead start with a constant stream of encrypted data with a rolling key [Preshared EG via carrier pigeon, codeworded news stories, broadcast in ciphered morse by hooking a capacitor to the prison bars, or sent in a charge controller chip with PGP over ebay], to never require your network traffic to travel over known monitored trans-regional and international backbone junctions, never be easily tied to a unique IP address or MAC or subscription to an ISP, never worry about attackers running dozens of analysis and sniffer nodes in the network, and ideally never worry about "what you say can't hurt you".

​

######################

Icu2/P (I see you, too!) suggested modifications to anonymous network architecture

​

Node = A computer participating in the I2P network. Hopefully it isn't a network tap, or a virtual node in a honeypot network.

Tunnel = How I2P gets traffic from one end to the other, through many nodes, using many protocols, in a semi-anonymous fashion.

Pipe = Idea to make I2P much safer from outside attack and analysis, and a little bit from evil snitches.

Anonymous = A joke.

Single Point of Failure = You name, address, SSN, DoB, leaked WebRTC IP address, nontransient online pseudonym, permanenet node ID, cross domain browser or hardware fingerprint, software exploit, operating system telemetry, leaked permacookies, hidden x86 MSR RISC backdoors [Intel's AMT, Supermicro BMC, AMD PSP, etc], email address, background photo siphoning, correlation exposing conversations, keyloggers, speculative execution and caching attacks, ...

Buffer = A pool of data that can act as a shock/lag absorber

VPN = A single encrypted container around network traffic, usually non-continuous and never truly anonymous. >~85% bandwidth efficiency.

Obfuscation = Tries to avoid deep packet inspection and next-gen application firewall signature matching. Might be able to combine with Pipes.

Operating System = What a real anonymous network could be.

Quality of Service [QoS] = A feature in better routers that will allow you to have a stable dedicated pipe architecture at the same time as your games and videos, necessary on shared networks unless the Analysis Security Certainty Factor has a good AI adjuster behind it.

ISP = Internet Service Provider. If you have ATT or Verizon you should stop reading ... >here< (IX still needs to add a shield on Kansas City)

​

1. Pipes are encrypted omnidirectional bandwidth containers for all direct node-to-node overlay network traffic.
2. Pipes are always on. They need as stable throughput, hop-to-hop, and packet tx&rx processing/timing delay as digitally achievable.
3. There is one pipe per direct node-to-node connection through which all traffic flows. There can be many pipes, or a few, depending on how many connections to other direct non-anonymous [see the moon bounce method] nodes there are.
4. Data can be split across pipes, meaning: over network interfaces [wifi(s), cellular(s), fiber(s), cable(s), satellite(s), P2P, mesh, ionosphere, ...], aggregation/ combination of all network bandwidth [can speed bandwidth to one direct node or increase rudundancy or anonymity by splitting data until an anonymous aggregation tasked node or the final end node], split tunnels, multi-homing in case a route goes out mid-way, etc. This has a major anti-analysis (read "anonymous network killer") bonus. Almost as big as that gained from constant pipe data and delay, if done right. [Aka Data should be completely free to roam around the network, in part or in whole, taking varying paths and routes to its destination. Even if evil nodes see some spidered incomplete traffic, they cannot piece it all together with certainty without network dominance.]
5. All pipes to and from a node act and nearly look the same [should be completely pseudorandom no patterns]. No actionable details about nodes or tunnels should be observable by analyzing pipes, packet headers, packet data, bandwidth, or packet delay except that data which is used to create and sustain the pipe over the Clearnet. Extremely robust stream ciphers are needed, and packet type should be as low overhead with the least operating system Nagling buffer as possible. It should be the formally verified hardware's job, whereas operating systems may introduce additional delay according to processor load or other insecurities that could jeopardize the anti-analysis protections. [OS, NIC, and Routers can introduce screw ups because of packet conformity and standardization, see Vault7 FluxWire]
6. The pipe stream can be built using a buffer of pseudorandom data (not simple padding), with real information, like tunnel creation requests, injected into the stream as not to cause any delay to the transmission or reception of the working pipe's packets or other pipes' packets of the node or connecting nodes.
7. Pipe stream data, post-injection and before transmission, should further be securely encrypted as to remove injection point AND structured data markers in the transmitted stream. You may choose a perfectly sized authenticated block cipher here, or an authenticated stream cipher. Prefer the latter. https://competitions.cr.yp.to/secret.html
8. Additional tunnel delay should be added by nodes every inter-hop, and of pseudorandom duration with respect to tunnel/circuit identifiers giving up routes. (Not based off a hard-coded or weakly generated seed, changes at same time other identifiers and codes change, might need PTP node groups to synch, see Jun27 update linking to topology grouping and role assignment on /r/Kovri) Again, not in a way that affects pipe packet transmission or reception, bandwidth or timing in a statistically determinate manner. Don't use tight or otherwise predictable delay windows. This is to negate any delay ananlysis nodes an attacker has running inside the network. You can't delay everything by 1 +/- 0.5 seconds and expect it to create random deviation. Modifications will need to be made to give long-standing evil nodes a hard time. [Relays batching and mixing stream 'cloves'.]
9. Anonymous tunnels may adopt features of pipes [and other Anonymity network designs like Loki,Tor,I2P,Sekreta,HORNET,Nym,Loopix,Jami,Freenet,WireGuard...] to combat attacker nodes running analysis that are able to see within the pipes and overall network layout and participation by design. I am unsure whether I2P does this effectively enough with any connection protocols.
10. Each pipe is monitored and ranked for its bandwidth, delay, traceroute, connecting node temporary identification, headers, data incongruities, fluctuations of the aforementioned, node schedules, and general reliability. This is used to balance a node's total stable network-ability among pipes and groups of pipes or nodes [or groups of nodes]. Data from each node can be collimated, particularly traceroute and path statistics via opt-in, to create shared databases of slow internet providers, blockage, throttling, bad routers, nodes, attacks taking place, etc. This data may be accessible on a node's administration statistics page with different kinds of graphical charts available, pertaining to graph theory. If loading peered network statistical data is done insecurely and without sanitization, as is anything else, a redesign is in order (and a kick in the @$$).
11. Each pipe and grouping of pipes is adjusted for stability according to the node admin's "Analysis Security", or 'preventative certainty factor'. This can be automatically adjusted using PID, machine learning, manually, or otherwise. Recommended options are if they want the pipe bandwidth to fluctuate 16, 8, 4, 2, or <1% of the time according to their ISP interface connection stability. [Or a custom default value that is even lower variation, due to the months-long attack studies everyone is doing. Good QoS comes in for the win here.]
12. Warning: If pipes are allowed to be throttled significantly enough to impact tunnel formation and tunnel traffic flow then a well organized [read "anyone with a plan"] attacker can force a known route to be taken or use it to improve their 'statistical' flow analysis. Pipes by themselves being steady as a rock makes it much harder to follow versus the standard unidirectional one-to-one or NTCP2 padded packet tunnel.
13. Tunnels now have a much simpler job: make sure attacker nodes get as little information as possible while forwarding traffic. Permanent node identification, tunnel creation, eepsite discovery and name registries, reseed servers, exploratory tunnels and everything else need to be reenvisioned to not give any good lasting information to an attacker(s) operating inside the network. Refer to: "single point of failure", because it only takes one.
14. Copious amounts of data leak and exploit prevention are recommended. Isolation is a key factor, but is too often used as a crutch for bad code. [See 'reasonably secure operating system']
15. Edit Jun 27 - Over time, the statistics gathered by all direct nodes, along with the tracking of changing temporary node identifiers allows a few scattered anonymous direct nodes to maintain tabs on your connection to the network (aside from the fact you have a unique connection signature over the clearnet). Having these ephemeral / transient accountability and statistics tables nets some innate ability to keep tabs on who might be a slow or evil node, or whose connection is straight garbage. Attacker nodes can track and make their own tables regardless of whether everyone else is or not. Node ID changes should occur frequently and be accompanied immediately, via delayed, random rolling or otherwise, having some or all direct nodes disconnect from the interface, thus establishing a new connection to new nodes with a new ID to avoid large statistics tables and attack windows. Using multiple interfaces enables your local client node(s) to maintain different sets of now-transient identifying information. Most users will only change their real singular IP address every few weeks when their modems request a new DHCP address from their ISP.

​

To be fair to the engineers, you should run pipes through tunnels, not tunnels through pipes. Just never say that it can't be done.

######################

​

That took a little while to type. I had space for a new point inbetween 9 and 10 on the notes from 2 years ago, so theres probably more knocking around in there somewhere. I'm here for questions if you need me to explain something.Edit: It may read redundantly, but I'm not sure how many ways I have to explain something for someone to get the picture. Advice welcome.

​

Edit May 25: I've been thinking about the timing reliability that all the Pipe VPN packets would need to be sent at, and want to suggest that something like Precision Timing Protocol be used to accurately determine [to a much higher degree than any form of NTP] the clock drift and other statistics between nodes with the standard continuous-bandwidth Pipes. I know that timing can be determined to <100 nanoseconds using PTP over leased dark fiber lines [from NIST on one side of the country to USNO AMC in Colorado Springs], and less so with standard backbone communications equipment [due to processing time and queuing]. Using anything but highly accurate and precise methods can allow fingerprinting and traffic deobfuscation both inside and outside the network. Also a highly accurate sort of fingerprinting would be possible knowing these clock timing & drift statistics.

Edit Sep 2 [Changed wording again, added WireGuard in #9 refs]: Modern high end network tap equipment can copy packets and tag them within 5ns, synchronized to their own local UTC source within 3ns at the extreme end of the bell curve, which is only ever off from UNSO-UTC or NIST-UTC by about 40ns. Traffic flow and timing analysis attacks are a real threat to anonymous networks.

We will discuss the future of Kovri.  

Where: #kovri room on Freenode

Hi Kovri and Monero community, oneiric here. I just posted a new FFS idea to work full-time on Kovri for another quarter.

​

I appreciate all the support I received for my last FFS, and any love you show me for this FFS: https://forum.getmonero.org/6/ideas/91264/oneiric-full-time-kovri-developer-december-to-february

​

Developments will focus on expanding the test suite (unit/integration/fuzz), associated refactors/bug-fixes, and working toward integration with Monero.

​

Thanks for reading, love you all!

From a GitLab issue: https://gitlab.com/kovri-project/kovri/issues/1000

"Hard fork the I2P network, or design/implement a new system, or implement another existing system

We have gathered enough evidence over the years to finally propose this issue. Not to be taken lightly, I will present a very clear proposal and finish writing this issue after defcon.

The most recent of many poor decisions made by Java I2P project have proven to be the straw that broke the camel's back.

Details to come."

What is happening?

Thanks /u/medoelma7al for this huge work.  

The new localization was included by two merge requests: one in kovri-docs and another one in kovri-site

As the title says, will a Kovri node get you in trouble as Tor would?

I'm not referring to the fact that the software is only in alpha stage and could have bugs that could allow an attacker to take control of your machine. (it will be a dedicated machine)

I'm looking for some help compiling the alpha release, was going to ask on #kovri but it appears I have to be a member and authenticate in. I'd like to join. Can someone help me with that?

what's the current status of kovri....

Why did the dev's decide to build Kovri rather than using the existing C++ I2P implementation: https://github.com/PurpleI2P/i2pd

hi i m running a monero stagenet full miner node how can i use kovri to hide and jumble my internet traffic while using windows 10

I recently stumbled upon ricochet, which is a anonymous peer-to-peer instant messaging app. https://github.com/ricochet-im/ricochet

Is there something similar based on kovri?

Can Kovri help defend against a DDoS and how should it be configured to do so?

Hello Kovri and Monero redditors! I'm oneiric, and am humbly asking for your support as a part-time Kovri junior developer for June to August.

Much more to come if the community likes my work.

I appreciate your contributions, attention, and/or feedback: https://forum.getmonero.org/6/ideas/90300/oneiric-june-august-part-time-kovri-junior-developer

Kovri PR

The worst thing you can do is overcomplicate something. Overengineering a process, especially with PR, is more often than not a waste of time. Time is life's most precious commodity, so let's cut through the bullshit and find a direct route to our audience(s).

What is/are Kovri's audience(s)?

For each audience, what does Kovri want to communicate at this point in time?

How/where does Kovri communicate with each audience?

Thoughts:

Assign someone to cover/manage a specific audience.

The person in charge of a specific audience will work with the Kovri community to craft a message for that audience. As the project develops, this message will need to be updated.

The person in charge of a specific audience will take the message and share it with the audience. This can be done (dependent on the audience) via e-mail, phone/video conference, appearances on podcasts, meetups, or conferences.

Note: This is not a directive. It is food for thought ahead of the meeting.