Opened 3 years ago
Closed 11 months ago
#18121 closed enhancement (wontfix)
anti-conformational attack (theory)
| Reported by: | bo0od | Owned by: | cypherpunks |
|---|---|---|---|
| Priority: | Medium | Milestone: | |
| Component: | Obfuscation | Version: | |
| Severity: | Normal | Keywords: | |
| Cc: | proper | Actual Points: | |
| Parent ID: | Points: | ||
| Reviewer: | Sponsor: |
Description
The design is simple inside this image:-
with this design if im getting it correctly , it will be very hard to make a conformational attack or at least very hard also to compromise the GW (Whonix GateWay = medified debian + Tor).
Note:- this design is very possible to happen inside Qubes OS + Whonix OS
The explanation:-
there will be for e.g. five DisposableVM (amnesic VM) which they are connected to the WS (Whonix workstation = medified debian + TBB) , but in fact they wont be working together how?
if u c the refresh icon it means the DisposableVM is turning OFF and going to be ON again after few minutes. while others r still working , and by this we get:-
continuing connection to workstation (working area) , and anti-compromisation to Tor , because the disposableVM will keep shutting shutdown itself and start again from point 0.
the green lines means the disposableVM is working, and red lines means disposableVM is refreshing itself by turning on/off itself from time to time (automatic off/on switcher).
i dunno if my guess is right or wrong. hope i c some activity to this idea.
for more info visit:-
Child Tickets
Change History (8)
comment:1 follow-up: 4 Changed 3 years ago by
| Component: | Quality Assurance and Testing → Analysis |
|---|---|
| Milestone: | Upgrade Tor's VM Infrastructure |
| Status: | new → needs_information |
| Version: | Tor: unspecified |
comment:2 Changed 3 years ago by
| Component: | Analysis → - Select a component |
|---|
comment:3 follow-up: 5 Changed 3 years ago by
| Resolution: | → invalid |
|---|---|
| Status: | needs_information → closed |
This doesn't seem directly Tor related at all, and going from 1 to effectively 5 Guards will do bad things to client anonymity.
The current proposed design for guarding against certain types of traffic analysis attacks is available at: https://gitweb.torproject.org/torspec.git/tree/proposals/254-padding-negotiation.txt
comment:4 Changed 2 years ago by
Replying to teor:
There isn't really a Trac component for what you're suggesting. Perhaps try contacting the Qubes / Whonix projects directly?
how they suppose to help me while im describing things Tor/anonymity specifically? the design true is based on their os but its not the core of discussion if the design happens to be in another OS or environment.
comment:5 Changed 2 years ago by
Replying to yawning:
This doesn't seem directly Tor related at all,
seriously -_- , how many Tor do u c in the design? its all about Tor thats why i mention it here.
and going from 1 to effectively 5 Guards will do bad things to client anonymity.
The current proposed design for guarding against certain types of traffic analysis attacks is available at: https://gitweb.torproject.org/torspec.git/tree/proposals/254-padding-negotiation.txt
so connecting to 1 node its better than 5 nodes? thats something i dont really imagine how. do u have some docs/papers explaining how is that going to be bad?
but what i do think someone would think this design is bad , is because of the continuous changing to the entry guards from time to time = and thats completely right.
but Tails then is severely fallen into this issue , and what im suggesting is kinda similar to multiple Tails with no TBB inside them (instead of DisposableVM) connected to any (secure as much as possible) operating systems with a TBB inside them (because this will gain the security through isolation of Tor from TBB = security by design or isolation).
so even if my idea is bad regarding entry guards then whole Tails idea is also bad. and if we say that my idea is bad to anonymity similarly as Tails then i dont think it is a bad idea at the first place because Tails is known for the issue regarding entry guards but tho it is well useable in the anonymity field.
lastly i say:- maybe im missing the whole point from the beginning , i dunno for sure. because im not professional in the Tor connectivity field but im good in imagining things and link them together = logic. and i do know also logic is not a big deal without linking it witha technical reality of the matter. but thats why i have given my design to be discussed with u ppl here.
(pinning this subject under "invalid" is really miss understanding to the subject itself)
thnx
comment:6 Changed 2 years ago by
| Component: | - Select a component → Censorship analysis |
|---|
comment:7 Changed 2 years ago by
| Resolution: | invalid |
|---|---|
| Status: | closed → reopened |
comment:8 Changed 11 months ago by
| Component: | Metrics/Censorship analysis → Obfuscation |
|---|---|
| Resolution: | → wontfix |
| Status: | reopened → closed |
Moving this to the "Obfuscation" component (not a perfect match) because it's about resisting traffic fingerprinting.


There isn't really a Trac component for what you're suggesting. Perhaps try contacting the Qubes / Whonix projects directly?