Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - kmfkewm

Pages: 1 ... 196 197 [198] 199 200 ... 249
2956
The main flaw I can think of in making it public is that it will give LE the ability to confirm suspected addresses, or to run through huge lists of addresses until they find matches, it is almost impossible to reverse a cryptographic hash but its trivial to get output from one with a given input and see if it matches up to listed hashes. Salting takes care of this, but if the salt is public then its worthless to protect from anything but rainbow tables, and rainbow tables are not really applicable to this anyway.

2957
Quote
Note: once you choose a hashing function, you should stick to it. Also, obviously if buyers play games with their addresses e.g. deliberate mis-spellings, then there's not a lot you can do about it. But, if you see something obviously misspelt, that is a 'red flag' for you. Doesn't mean they are scammer, it could be the buyer is trying to ensure more of the so called 'plausible denialability', but still.

Fuzzy hashing could help eliminate that unless the customer horribly misspells shit. Instead of hashing the entire address, split it up into chunks of say 5 bytes, then hash those chunks. Now if they make a single misspelling, there will still be a % match to the previously stored hash that will be statistically higher than normal. This will take a bit more work to do. You also generally want a big input when working with fuzzy hashes, an address doesn't really give a whole lot of data to work with (versus say a 1megabyte image that you want to be able to detect even if it has had some graphics editing done to it), and if the sections are too small it will make brute forcing easier and make salting much more required and also since it is such a small input and addresses are sometimes close it could lead to some false positives.

Right now I would like to find a list of all possible legitimate ways to write out the same address, so I can have my script standardize them prior to hashing.

edit: since it was Pines idea and he/she/it seems keen to write the script, I will discontinue mine. What language are you going to write it in Pine?

2958
Code: [Select]
require 'digest'

puts "Enter a constant salt to further protect stored address hashes:"
salt = gets.chop


puts "Remember to remove the customers name and only include the address"
puts "paste address, end with # followed by a newline"
address = gets("#").chop


address.downcase!
address.strip!

while address.sub!(/[\n*]/, '') do
address.sub!(/[\n*]/, '')
end

while address.sub!(/[" "]/, '') do
address.sub!(/[" "]/, '')
end

digest = Digest::SHA256.new
obfuscated_address = digest << salt + address

if File.exist?("#{obfuscated_address}") then
File.open("#{obfuscated_address}", 'r') do |read|
while line = read.gets
puts line
end
end
else
puts "New customer!"
end

puts "Enter any new comments you have about this address, end comments with # followed by new line"
comments = gets("#").chop

File.open("#{obfuscated_address}", 'a') {|f| f.write("\n\n" + "My Comment:" + "#{comments}" + "\n\n") } if comments.length > 0

It could be much nicer, but I wanted to not have to include any fancy gems. This takes an address, removes all new lines and white spaces, makes everything lower case, and takes its SHA-256 value. You are first asked to provide a salt, this can be a pretty simple string and still offer significant protection, it is mainly to protect from an attacker who gets the hash list comparing random addresses to hash values until they hit on one. This script should be run from a newly created directory because it creates new files named whatever the hash ends up being, and comments are stored in these files. When an address is entered for the first time the file is created and users can leave comments, every other time the comments are displayed and the user can add more comments. It's really basic but it does take care of basic formatting issues and hashing for you, it is Ruby so does require you to have the interpreter but doesn't require anything that doesn't come with the standard interpreter.

edit: hmm I guess I need to use regular expressions to find all formats data can be stored in and standardize it to make sure the hash value can not be thrown off by customers putting their address in different formats. Anyone want to help with a list of ways that the same thing can be written, in regard to addresses?

2959
Vendors should be deleting addresses as soon as shipped.  If you printed off for some sort of packing sheet, burn the fucker the second the last pack hits the last envelope.  Done.

The only thing I keep i a list of usernames for buyers who I will never ever do business with, mostly gathered via the forum posts on suspicious buyers, PMs with morons, and the odd horrible son of a bitch (and I could recite all of those off the top of my head) who has actually done business with me.

Yes, and you could use a hashing function for addresses (shouldn't count white-space or distinguish between upper/lowercase). A small script can do that rather neatly.

This way, you have a spreadsheet of IDs, and a counter that increments for each ID when it reoccurs.

e.g.

asdf234dfe453efe            1
23adsfw43533fda            5
aaqwergwerwera             0

0 could be an address, username or country on your black-list. Or you could use negative numbers for different meanings.

You can keep your promise to SR and it's clients, because every address is transmorphed into an ID.

If LE pick up the spreadsheet, even if they know what they have, they have to know how to reverse the hashes, and even when knowing what function you used, this is an extremely non-trivial exercise. Plus, you can't really help them even if you wanted to, since you can't reverse the hash either.

I think this is a pretty much watertight method of keeping statistics, without, ah, keeping LE relevant information. Anybody see any holes?

that is a good idea, just make sure to translate all addresses to a standardized form, because the value for Address and address is different

2960
what's to stop your local dealer from wearing a wire for half a year after he gets busted?

2961
Who gives a fuck if the cops think you are guilty or not they are not the jury, not to mention they already think everyone who isn't a cop is guilty of something and anything you say will be totally twisted by them 

2962
Off topic / Re: Bitcoin Pyramid
« on: April 28, 2012, 12:13 am »
Madoffs scheme was a Ponzi. Pyramid schemes are more like multi-level marketing, you pay money to join then you recruit others and make a % of their membership fee, usually they try to hide it by having some worthless product to sell along with it but the majority of it focuses on the membership and recruitment / referral fee structure. Ponzi schemes pay old investors with money new investors put into the scheme and they pretend to be investing in other things but really are not investing in shit. Ponzi schemes are insanely popular with e-currencies of all sort, just look up HYIP, high yield investment program. It really is like gambling with those things, the first few people who put money in get huge returns, but eventually the person running it takes off with everyones money. Some people are actually fooled by those things, many just treat it like gambling, if you get in early enough you do stand to double or triple your "investment", but if you get in at the wrong time you stand to lose everything.

2963
Security / Re: Is TOR bulletproof?
« on: April 27, 2012, 11:21 pm »
I want to address the issue that is foremost in the debates about security and privacy and anonymity. Just how secure is tor ***really***? I mean, mathematically I can surmise that it is the best we've got, but is it enough? With all these monster computers and algorhythms and spying machinery that the fucking government is ammasing against us, do we really stand a chance?

I don't want to sound like a wet blanket, but are our private days numbered?

The primary attack to worry about with Tor is end point timing correlation. Regardless of the number of middle nodes, if the attacker can watch traffic enter the network and arrive at its destination, they can link the traffic, meaning they can determine that the IP they saw sending traffic sent it to the location they saw traffic arrive. Pretty much the only way around this is to add enough artificial delay to traffic at each hop, that a large amount of peoples traffic can be gathered at the hop and reordered prior to being sent out. This is called mixing, but it generally requires too much time delay to get a substantial enough crowd, and isn't adequate for surfing the internet in a real time manner, it is mostly used for E-mails on networks like mixmaster and mixminion.

The first step of being able to watch both ends of traffic is to determine the target servers IP address (ie: the server you want to know who is visiting). If it is on the clearnet this is trivial, and you can monitor for connections to this server from your exit node. Clients create circuits that use a different exit node usually once every ten minutes. This is not as trivial to do against hidden services, although if you own a hidden services entry node you can trivially determine this fact and its IP address by doing a timing correlation attack, hidden services select entry guards. Entry guards consist of three relays selected from the pool of relays with the guard flag, that all traffic enters the network through. Guard nodes change every thirty or sixty days, and a hidden service uses the same guards for every client connecting to it. A hidden services natural 'exposure' to 'exit' (really entry) points is thus much less than a website on the clearnet. If the attacker can not monitor traffic arriving to the hidden service, they can not do an end to end timing correlation attack (although this does ignore website fingerprinting attacks).

Unfortunately, it is not that hard to trace a hidden service to its entry guards. Hidden services create a new circuit for every rendezvous node a client requests it to connect to, and malicious clients can request hidden services to connect to thousands of different rendezvous points simultaneously. Although the hidden service always enters through its entry guards, its middle and "exit" node (really not an exit, but last node from the hidden service) are selected from the total pool of Tor nodes, and are newly selected for each circuit. A malicious client doing this can also operate as a relay itself, and the hidden service is likely to select it as a relay for some of its circuits. The malicious client/relay can then do timing attack and statistical analysis to trace the hidden service up to its entry guards. This attack can be carried out with a single node and traces to entry guards in a matter of minutes.

At this point the attacker has two options. It is worth pointing out that there are two types of attacker, active and passive. Active attackers attack the network by adding nodes to it, passive attackers attack the network by monitoring the connections between nodes. For an active attacker to trace a hidden service, they need to own one of its entry guards. After they identify the hidden services entry guards, they will want to DOS them, forcing the hidden service to either go down (if strict entry guards are set in torrc, they are not by default), or select new entry guards (default behavior). One way to do this is by flooding entry guards with fake create cells, which cost very little processing power to construct but a significant amount to process. This allows the attacker to exhaust the processing power of the entry guards, effectively DOSing them. If they can continue to do this to all selected entry guards simultaneously, eventually one of the newly selected entry guards will belong to the attacker and thus they can deanonymize the hidden service. This is the best currently known active attack for tracing hidden services, and it isn't that expensive.

A passive attacker who traces to the entry guards can order the ISP of the entry guard, or other infrastructure (IX, AS) to put a trap and trace on the entry guard, this will allow them to deanonymize the hidden service without owning the entry guard, just being able to see all connections to and from it.

Once the hidden service is located, the attacker will monitor connections to and from it, this will give them one half of an end point timing correlation attack. Now your anonymity depends on the attacker not owning one of your entry guards, or being able to passively monitor you. Thankfully, it is significantly harder to speed up a clients entry guard rotation, so it will likely turn into a waiting game at this point, every 1-2 months you will select new entry guards and depending on how many entry guards the attacker owns there is a certain probability chance of them owning one of yours and being able to determine that you communicate with the hidden service they have traced. They will likely be able to deanonymize a small portion of the users every month to two month period, but Tor does a good job of preventing them from deanonymizing 100% of the users, at least unless they wait for quite a while, probably at least a year unless they have a large % of the total entry guards.

2964
Security / Re: Delete items in Recycle Bin
« on: April 27, 2012, 06:56 pm »
http://www.tomcoughlin.com/Techpapers/Secure%20Erase%20Article%20for%20IDEMA,%20042502.pdf

Quote
....positioning the heads ± 5-10% off-track. This defeats exotic recovery techniques, and also erases the track
edge signals (which will be shown to be primarily transition noise in the tests here, not signal).

Quote
Track edges can contain highly distorted original data as well as transition noise and are therefore difficult to
recover data from. Figure 2 shows a crosstrack scan of the residual signal, when a swath of tracks is DC-erased
(blue curve) and when a 20 MHz square wave is overwritten by 10.5 MHz (red curve), chosen so the
overwriting signal doesn’t have harmonics at 20 MHz. The scan does not change if the 20 MHz signal is not
written at all (black curve), so it must be entirely due to the overwriting 10.5 MHz. This means that although the
amplitude peaks 4-6 dB at the track edges, this cannot be unerased 20 MHz signal. A full spectral analysis
(Figure 3) shows that these track edge peaks are primarily ac-erased transition noise (the noise floor at 20 MHz
rises 4 dB above the DC erase level, when 10.5 MHz is recorded). The poor write field gradients off the head
sides ac erases a higher level of transition noise than the well-written 10.5 MHz transitions in the main track.

Actually this paper makes it seem like there are actual exotic attacks that using random data in the wipe helps protect from

Quote
One erasure pass appears to be sufficient to make old data unrecoverable. A two-pass erasure can provide an
additional level of security. Writing LF helps erase the track edges, and then overwriting with random data
defeats exotic techniques (see later section of this article). The two passes can be slightly off-track in the
positive and negative direction in order to ensure elimination of the track edges


in the end they do conclude that one pass is enough to make data unrecoverable, but they also say using random data and putting the head off center can add additional protection from exotic attacks

Quote
One erasure pass appears to be sufficient to make old data unrecoverable. A two-pass erasure can provide an
additional level of security. Writing LF helps erase the track edges, and then overwriting with random data
defeats exotic techniques (see later section of this article). The two passes can be slightly off-track in the
positive and negative direction in order to ensure elimination of the track edges.

even a very small partial recovery of data can be enough to do a full recovery in some cases, let's say you have the anarchists cookbook and you erase your drive but they get a few 512 bit segments of it from the track edges, that is potentially enough for a fuzzy hash match to identify it (provided they have a reference)

hm seems like if they don't know the overwrite pattern then they can't do it

Quote
Drive information can sometimes be recovered that has been erased using a single erasure pass on-track. It
should be first pointed out that single-frequency squarewave overwrite tests are not meaningful indicators of
information recovery. A spectrum analyzer can see -60 dB overwritten signals but it can’t recover data. The
CMRR technique requires reading a data block many times, computer averaging the playback waveforms, then
erasing the block and re-recording the overwrite data to obtain its averaged playback waveform data, which is
subtracted from the first waveform. The demonstration shown below merely means that it is possible, not that it
is practical or will work on any drive. It requires knowing the data pattern being looked for, and also knowing
the overwriting data pattern. So it “begs the question.” It can be defeated by using a random data overwrite
pattern.

Quote
Data recovery techniques showed that SE overwritten user data is beyond recovery by normal drive read
channels. But CMRR could recover overwritten user data by digital scope signal waveform averaging, software
correlation techniques. These recording experiments were done on a spinstand using a dual stripe MR head
2.5 μm write width, 1.8 μm read width, 2500 Oe/0.65 Mrt disk. These had 38 dB overwrite and a playback
noise floor -69 dB.
First a swath of tracks was DC erased, then arbitrary user bits “HELPHELP” were written, the playback
waveform was averaged 100 times to improve SNR, and saved as waveform 1. Then a random bits overwrite,
the same signal averaging, and saved as waveform 2. Another DC erase followed by overwriting with the same
random bits and signal averaging, is saved as waveform 3.
Figure 4 shows the averaged initial playback waveform 1, and the residual wave 3 minus wave 2. Not much
residual signal left!

Figure 5 shows results from a correlation detector. The residual correlation has a correct peak at zero offset,
which is about twice the second highest peak. This indicates that “helphelphelphelp” is correctly detected (but a
2:1 signal-to-“noise” ratio means high error rate). (When this was repeated with TWO random overwrites,
correlation detection did not work.)
Beyond these data recovery techniques which use drive hardware, other exotic techniques can be proposed such
as putting recorded discs into scanning magnetic force microscopes. It is easy to obtain pictures that appear to
show unerased track edge data. But no one has shown complete recovery of a data sector, including the data
synchronization preamble, bit de-randomizer, partial response and modulation codes, and error correction code.




Quote
“While it is certainly true that BEWTs cannot write to off-track areas, ATA-SE cannot overwrite off-track areas either. ATA-SE does a single on-track erasure of the data on the disk drive"

ATA-SE has two versions standard and enhanced. The standard version does a single pass wipe, enhanced does on track and off track wipe, and it can do this because it is firmware.

2965
Security / Re: Double Internet
« on: April 27, 2012, 05:26 pm »
it's perfectly safe unless you use the anonymous and non-anonymous browser to visit the same site at the same time , in which case it presents a risk of a correlation in stream breaking if your internet goes down

2966
Drug safety / Re: MDMA effects on middle aged people?
« on: April 27, 2012, 12:38 pm »
lol she is in her late 40s early 50s not 80

2967
Quote
I wouldn't shoot any of them or anything

Why not if you plan to kill yourself at least take out as many LE agents as you can with you

2968
Off topic / the thread with no strictly defined topic
« on: April 27, 2012, 09:50 am »
First I would like to apologize for making a poll asking about if threads should be censored here or not and taking jabs at moderators. It was clearly uncalled for and immature of me. This is your forum and you are free to run it however you like. In the spirit of keeping mods happy, I have decided to make a thread with no strictly defined topic. Nothing in this thread is off topic because the topic is not strictly defined. Since the thread "how young would you go" was locked because it went off topic (and not because a moderator found the topic to be personally offensive), I have decided to start this thread with the pseudo-topic of how young would you go, and I imagine it shouldn't be locked since no matter where it goes from here it will fall under the topic of not having a strictly defined topic.


2969
Shipping / Re: PO box questions[receiving bulk]
« on: April 26, 2012, 04:29 pm »
It will be expensive for them to do manned surveillance for so long, they might put a tracking device inside the package though or a device that alerts them when the pack is moved so they can send the nearest patrol car there ASAP

2970
Feature requests / Re: I BEG YOU TO MAKE THIS FORUM PRIVATE
« on: April 26, 2012, 04:21 pm »
Great idea I'm sure none of the 18000 people here are feds or reporters.

shit I thought I was on TFM for a second, then I realized you were being sarcastic and loled

Pages: 1 ... 196 197 [198] 199 200 ... 249