Opened 4 years ago

Closed 2 years ago

#18121 closed enhancement (wontfix)

anti-conformational attack (theory)

Reported by: bo0od Owned by: cypherpunks
Priority: Medium Milestone:
Component: Circumvention Version:
Severity: Normal Keywords:
Cc: proper Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The design is simple inside this image:-

https://forums.whonix.org/uploads/default/original/1X/258fdf25ca73641ee3610de4a6893ee6e001b60b.png

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 Changed 4 years ago by teor

Component: Quality Assurance and TestingAnalysis
Milestone: Upgrade Tor's VM Infrastructure
Status: newneeds_information
Version: Tor: unspecified

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

comment:2 Changed 4 years ago by teor

Component: Analysis- Select a component

comment:3 Changed 4 years ago by yawning

Resolution: invalid
Status: needs_informationclosed

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 in reply to:  1 Changed 4 years ago by bo0od

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.

Last edited 4 years ago by bo0od (previous) (diff)

comment:5 in reply to:  3 Changed 4 years ago by bo0od

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

Last edited 4 years ago by bo0od (previous) (diff)

comment:6 Changed 4 years ago by bo0od

Component: - Select a componentCensorship analysis

comment:7 Changed 4 years ago by bo0od

Resolution: invalid
Status: closedreopened

comment:8 Changed 2 years ago by dcf

Component: Metrics/Censorship analysisObfuscation
Resolution: wontfix
Status: reopenedclosed

Moving this to the "Obfuscation" component (not a perfect match) because it's about resisting traffic fingerprinting.

Note: See TracTickets for help on using tickets.