Re: Private Homes may be taken for public good

[Thomas Shaddack]

On Thu, 23 Jun 2005, Tyler Durden wrote:

> How do you take out a bulldozer?

Anti-tank mine?

Re: Stash Burn?

[Thomas Shaddack]

On Mon, 2 May 2005, Tyler Durden wrote:

> yes, this reminded me of another brilliant idea.
> 
> Why don't some cars have a little tiny furnace for stash destruction?
> 
> If you've got an on-board stash and some Alabama hillbilly with a badge pulls
> you over, you just hit the button and have you're little stashed incinerated.
> Who cares if the badge knows you USED TO have something on board? Too late now
> if any trace of evidence is gone.
> 
> What's wrong with this idea?

Let's focus on the technical realization first. How to annihilate a 
sizable chunk of matter without leaving even minute traces of it? We 
should keep in mind that contemporary forensic detection/analysis 
technologies are pretty damn sensitive.

We also shouldn't forget that burning the substance releases a 
considerable amount of energy, and takes time - at least several seconds. 
Soaking it with liquid oxygen could dramatically reduce the burning time, 
and lead to total oxidation to CO2/H2O/SO2/NO2/P2O5, but it also bears 
certain risk of explosion, and LOX does not belong between user-friendly 
substances as well.

The method also should not provide any hard evidence about when the 
incinerator was last used, in order to make it difficult to prove the 
exact moment of its deployment. This sharply collides with the requirement 
to dump the waste heat, as the unit will be pretty hot for some time after 
initiation, even if it will be directly connected to the car's heatsink.

Re: Your epapers, please?

[Thomas Shaddack]

On Thu, 31 Mar 2005, Major Variola (ret) wrote:

> At 10:08 PM 3/31/05 +0200, Eugen Leitl wrote:
> >   government plan to insert remotely readable chips in American
> >   passports, calling the chips [2]homing devices for high-tech
> >   muggers,
> 
> So the market for faraday-cages for your passport will grow to
> equilibrium.  A cage will cost less than a buck in parts, easily
> affordable by the clueful.  The damage to the clueless will
> quickly be the best advertising for the product.  Since we
> have been wearing conductive mesh burkhas for some time,
> the only inconvenience will be for the terahertz voyeurs
> employed by the TSA.

Beware of one gotcha. Faraday cage will shield only the electrical 
component. Low-frequency tags (125 kHz, typically) are magnetically 
coupled. Experiments shown that such tag is readable, even if entirely 
wrapped in aluminum foil. Laying a tag on top of a feromagnetic surface 
(iron sheet) does not help (probably only diminishes the range, didn't do 
the exact measurements yet); the sheet has to be between the tag's coil 
and the reader coil to be effective.

Putting the tag into an enclosure made of a feromagnetic material helps, 
though. Altoids can proved to be a pretty effective shielding.

Re: SHA1 broken?

[Thomas Shaddack]

FPGAs will have very hard time to be as fast as "dedicated" CPUs, 
frequency-wise. The FPGA structures have to be too generic, and are much 
bigger than specialized structures of the CPUs, so they have higher 
capacity, which limits the maximum achievable switching frequency. The 
length of the wiring between the structures together with the lazy speed 
of light plays its role as well. However, the FPGA structure allows 
parallelizing of processing tasks, which can in some cases neatly beat the 
sequential CPUs.

There are FPGAs with on-chip RISC CPU cores, allowing reaping the benefits 
of both architectures in a single chip.



On Sat, 5 Mar 2005, Tyler Durden wrote:

> Well, what would you call a network processor? An FPGA or a CPU? I think of it
> as somewhere in between, given credence to the FPGA statement below.
> 
> -TD
> 
> > From: "Major Variola (ret)" <[EMAIL PROTECTED]>
> > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> > Subject: Re: SHA1 broken?
> > Date: Sat, 05 Mar 2005 06:51:24 -0800
> > 
> > At 09:23 PM 2/19/05 +, Dave Howe wrote:
> > >   I am unaware of any massive improvement (certainly to the scale of
> > > the comparable improvement in CPUs) in FPGAs, and the ones I looked at
> > a
> > > a few days ago while researching this question seemed to have pretty
> > 
> > FPGAs scale with tech the same as CPUs, however CPUs contain a lot
> > more design info (complexity).  But FPGAs since '98 have gotten
> > denser (Moore's observation), pioneering Cu wiring, smaller features,
> > etc.
> 
> 

RE: Team Building?? WIMPS!!

[Thomas Shaddack]

On Thu, 10 Feb 2005, Tyler Durden wrote:

> Well, I didn't say it would be easy. We'd definitely need to split up into
> teams...one to handle the alarm systems,

Teamwork is essential here.

Maybe attract a lightning with a rocket on a wire[1], the induced current 
will do the job with the sensors around. Optionally annoy the sensors with 
spurious alarms until they get written off as unreliable[2]. Keep 
disabling the technicians that come to check/repair them[3], until the 
base staff either runs out of technicians or writes off the sensors. 
Technology can be a strength, but overreliance on it is a weakness.

[1] I believe lightning researchers do this, in addition to having labs on 
tops of skyscrapers. See eg. .

[2] US agents did it with sugar pellets shot at the windows of the 
Russian embassy in Washington, DC, during the thunderstorms that are 
frequent there. The vibration sensors were causing false alarms, so they 
were disconnected. Then one night the agents successfully penetrated the 
object. Same with rebels in Afghanistan attacking Russian bases. (Bruce 
Schneier, Beyond Fear, page 56:
)

[3] I think it was used during WW2. The comm wires were cut, then the 
soldier dispatched to check the failure was ambushed. Used frequently by 
guerrillas fighting Germans in the mountains.

> one to handle the landmines,

Optionally just add couple more mines and then wait.[4]

[4] As a classic joke says. A farmer had a pumpkin field. Neighbourhood 
boys were stealing them. One day, he put up a sign: "One of the pumpkin is 
laced with cyanide." In the evening, he found scribbled there: "Now they 
are two".

> one to somehow fend off May's bullets.

History books are full of prior art.

Or just drive a remotely controlled tank in.

Or modify the strategy. As Sun Tzu says, the best battles are the ones won 
without fighting.

> And then, even if we somehow capture May, I'd bet he's got all sorts of 
> dead-man stuff like poison gas and whatnot. It'd be like a big game of 
> D&D, not that any Cypehrpunk knows what THAT is!

It would be closer to a LARP.

> And yeah, there's a good chance someone's not gonna make it. But think of it
> like this: Those genes were slowing down our species anyway.

The best fun often has the highest price.

> The only problem is, what do we do once we're in? Throw a big-ass drinking,
> whoring Shriners-like party? (I say we need a bevvy of black hookers.) Break
> into May's survivalist supplies?

Don't worry. Look at the Iraq Desert Adventure planning stage. Who needs a 
post-victory plan?

Re: campus network admins

[Thomas Shaddack]

On Thu, 4 Nov 2004 [EMAIL PROTECTED] wrote:

> 
> I recently violated the network user agreement (they packet-sniffed and
> got the username/password for my FTP server and didn't like what I was
> sharing with myself) and was informed by the admin that I am now 'under
> observation' and that they "hope I don't like privacy". Considering
> this admin was an NSA employee, I tend to take that threat a little
> seriously.

Depending on how trivial the violation was, it may be worth checking the 
FTP server logs, identifying the bad ones and collecting the evidence, and 
eventually, preferably after consultation with a lawyer, nail the admin 
with hacking charges. (Alternatively just threat with the same, with a 
remark that you hope he likes lawyers. I suppose you're located in the 
Land of Lawyers.)

If it is better to play a repentant sinner, or go to a confrontation, 
depends on many more factors unknown to us, including the exact text of 
the network AUPs, the personality profile of the admin (he may be just 
power-tripping at you, but the severity of his threats depends on the 
exact content of your disk which you didn't specify), and other factors 
like if you are an employee or a student and how much risk you want to go 
through.

Violating AUPs with cleartext protocols isn't a good idea, especially with 
nazi admins. Next time you may like to prefer ssh/scp, or WebDAV over 
HTTPS, or a simple password-protected upload/download interface written in 
PHP or as a CGI script, again over HTTPS (you may like to use one-time 
passwords for added security).

If the admin in question can have physical access to your machine, put the 
sensitive/objectionable data on an encrypted partition.

> Two questions:
> 
> 1) I'm assuming they can legally look at anything that comes in or out
> of my computer, but is that the case? Can they look at my computer
> itself, or take me off the network for the private contents of my
> computer?

That depends a lot. If you're in a suitable uni campus, you may try to 
consult with local law students. This question is something a mere 
technician can't reliably answer.

> 2) Is there some sort of service I can use to have everything I do on the
> network encrypted, such as a tunneling service to the internet?

Yes. Depends on what you want to do; if you want to be independent on any 
special software installed on the computers you're operating from, I 
suggest a HTTPS server, with a self-signed certificate (cheaper), and 
manually check its fingerprint when connecting. For upload you may use a 
web file upload form. Don't neglect the certificate check; the admin may 
like to start playing games with you and launch MITM attack at your 
connections. Do the fingerprint check even when the browser claims all is 
OK.



> 
> ~
> This message was sent from The Tedious Path
> Are you ready to travel The Tedious Path?
> http://www.tediouspath.com
> http://forum.tediouspath.com
> 

Re: Airport insanity

[Thomas Shaddack]

On Tue, 19 Oct 2004, James A. Donald wrote:

> The US government should expose and condemn these objectionable 
> practices, subvert moderately objectionable regimes, and 
> annihilate more objectionable regimes.  The pentagon should 
> deprive moderately objectionable regimes of economic resources, 
> by stealing their oil, destroying their water systems, and 
> cutting off their trade and population movements with the 
> outside world.

Meanwhile, the world will get pissed, Arabian Bloc will finally agree on 
the concept of Monetary Jihad and switch from dollar-per-barrel to 
euro-per-barrel and later perhaps even to a gold-backed Islamic Dinar. 
Arabs have difficulties to agree on something, but give them an enemy and 
they flock together (not entirely unlike Americans) and make decisions.

Once the switch is done, there will not be the necessity to keep so high 
dollar reserves anymore. The USD will lose most of its market power and 
gradually becomes Just Another Currency.

Other countries will stop caring about unilateral embargos and will trade 
with the affected areas anyway, to great dismay of American planners. US 
will attempt to retaliate and cut trade with the offenders. However, the 
world is big and patents on embargoed goods aren't usually respected in 
the affected areas. Also don't forget that you foolishly offshored most 
manufacturing years ago, so patents or not, the rest of the world will 
keep buying Taiwan and China and Malaysia and Japan. And Ireland-made 
CPUs. The transnational corporations won't have the incentive to respect 
US-imposed rules, as they will cut into their profit; the ones that didn't 
made it yet will move outside of the influence of US law, with the 
corresponding impact on US tax revenue and the ability to finance further 
military adventures. Hey - even students are already increasingly choosing 
non-US universities and scientists are in process of moving conferences 
elsewhere, in long term influencing your ability of weapon research, 
further weakening you military-wise. Your policies are signing your own 
demise, and your beloved free market will stab your own back.

Meanwhile, the Empire will cut itself off the world, in a failed attempt 
to punish the world for non-compliance.

What will you do then? You can't bomb everyone. The world needs you much 
less than you like to think.

Now, when you see PNAC won't work, what's your revised plan?

Re: Airport insanity

[Thomas Shaddack]

On Sun, 17 Oct 2004, James A. Donald wrote:

> 
> --
> James A. Donald:
> > > > > If you really look like the shoe bomber, then you 
> > > > > should have to drive, or use public transport.
> 
> Thomas Shaddack
> > Ever tried to drive to Europe? Or to Hawaii?
> 
> Hard biscuit

Do I interpret this statement correctly as the endorsement of 
ethnicity-based travel restrictions?

Didn't domething like this been here already, in the form of Jim Crow 
laws, and later found unconstitutional?

> > Why airplanes don't count as a form of public transport?
> 
> They do.

I am afraid either I don't understand you correctly, or you are 
contradicting yourself. The "...or use public transport" from your earlier 
statement seems to mean that you said something along the lines "if they 
can't fly, they should use public transportation, which includes 
airplanes".

> > This is a measure good for pissing off (which is often the 
> > first step to radicalizing) the quite secularized majority of 
> > American Arabs.
> 
> The proposition that we need to walk delicately for fear of 
> disturbing the tender sensibilities of arabs seems laughable. 

Being told I can't use some quite common resource, in this case an 
important means of transportation, because of so irrelevant factor as 
ethnicity, isn't exactly delicate. What would you do if you'd be in the 
receiving end of such policy? Add more such restrictions and some 
percolating time - would you just bow and obey? How long it would take to 
get you pissed and eventually revolting?

> Are the arabs walking delicately to avoid offending our 
> sensibilities?

Vast majority of them yes. But you don't perceive them because they don't 
offend you and don't make the news.

> > You also seem to forget there is another potential factor - 
> > not only the visible one (ethnicity), but also one that isn't 
> > obvious to visual evaluation - religion. There is a 
> > significant black minority that inclines to Islam, some of 
> > them potentially radical. Do you want to suggest banning 
> > blacks from flying too?
> 
> Seen any black suicide bombers?

Not yet. But maybe I just didn't look deep enough through the mass-medial 
fog of the terrorism "war".

> Black Muslim radicalism tends to express itself by mugging Jews and 
> stealing television sets. Strapping dynamite to one's chest just does 
> not seem to be a black thing.

With the proper leadership, everything is possible. Don't forget the 
WW2 kamikaze pilots, who weren't quite Arabs.

Re: Airport insanity

[Thomas Shaddack]

On Mon, 18 Oct 2004, James A. Donald wrote:

> Sadre protected himself with Iraqi women and young children as
> human shields, showing that he expected the Pentagon to show
> more concern for Iraqi lives than he did. 

Pentagon protects their people by distance - being it by bombing from high 
altitude, or by using cruise missiles.

Everybody uses the technology available to them. What's bad on it?

Invariably, the side that uses the defensive measure - being it smart 
weapons[1] or human shields - classifies it as tactical, while the other 
side considers it cowardly.

A nice example of symmetry in asymmetry.


[1] The defensive aspect here is to allow the attackers to attack from 
distance beyond the reach of the other side's active defenses, thus not 
risking anything more than a piece of overpriced electronics.

RE: Airport insanity

[Thomas Shaddack]

On Mon, 18 Oct 2004, James A. Donald wrote:

> Thomas Shaddack wrote:
> > It isn't a problem for you until it happens to you. Who knows 
> > when being interested in anon e-cash will become a ground to 
> > blacklist *you*.
> 
> I know when it will happen.  It will happen when people 
> interested in anon ecash go on suicide missions.   :-)

Never underestimate the power of the combination of the People With 
Agendas with Classified Computerized Profiling Algorithms. :)

Be vigilant.

> People who are, for the most part, not like us are trying to kill people 
> like us. Let us chuck all those people not-like-us off those planes 
> where most of the passengers are people like us.

Define "us"?

> This really is not rocket science. 

Personally, as a relatively frequent flyer, I worry much more about things 
like cutting corners of fuselage and engine maintenance and quality of 
fuel (and, perhaps even more, the quality of onboard coffee) than about 
bombers on board. (On the other hand, local states grew out of their 
imperial-lust phase couple decades/centuries ago, which makes their people 
less disliked. Somehow lesser tendency to trigger-happy gung-ho a-ramboin' 
seems to be helpful too.)

Seeing things in perspective sometimes helps.

RE: Airport insanity

[Thomas Shaddack]

On Mon, 18 Oct 2004, James A. Donald wrote:

> > a.  The probability ratios don't work out so that the 
> > overwhelming majority of people you throw off planes are 
> > innocent.
> 
> Provided the number of people you throw off planes is rather 
> small, I don't see the problem.

It isn't a problem for you until it happens to you. Who knows when being 
interested in anon e-cash will become a ground to blacklist *you*.

Do you propose a way to appeal the decision? Will the flight (and 
associated losses, eg. lost contract due to a missed meeting, etc.) 
reimbursed?

Re: Airport insanity

[Thomas Shaddack]

On Sat, 16 Oct 2004, James A. Donald wrote:

> > > If you really look like the shoe bomber, then you should have to 
> > > drive, or use public transport.

Ever tried to drive to Europe? Or to Hawaii?
Why airplanes don't count as a form of public transport?

> > So by that rationale, every Arab should have to drive?
> 
> Every young male Arab past puberty, with a few exceptions for 
> special cases.

This is a measure good for pissing off (which is often the first step to 
radicalizing) the quite secularized majority of American Arabs.

You also seem to forget there is another potential factor - not only the 
visible one (ethnicity), but also one that isn't obvious to visual 
evaluation - religion. There is a significant black minority that inclines 
to Islam, some of them potentially radical. Do you want to suggest banning 
blacks from flying too? If so, what reaction are you expecting to get?

Re: RFID Driver's licenses for VA

[Thomas Shaddack]

On Thu, 7 Oct 2004, Sunder wrote:

> So the cops and RFID h4x0rZ can know your true name from a distance.  and 
> since RFID tags, are what, $0.05 each, the terrorists and ID 
> counterfitters will be able to make fake ones too... Whee!

Given the power requirements for doing anything more than dumb sequence 
repeat, I'd worry about the potential for replay attack and licence 
cloning.

Make a proof-of-concept device early after they start rolling the scheme 
out, publish on Slashdot, and see them retracting it as fast as they were 
deploying it.


A defense is a metal board in a wallet, close to the RFID chip's antenna. 
It is readable when the licence is taken out of the wallet. When inside, 
the antenna is quite effectively shielded. As a bonus, for many people 
this method can be seamlessly integrated to their mode of the document 
usage (leaving the privacy implications of the "legitimate" readers aside 
for now, talking about the unauthorized remote readers only here).

Re: Foreign Travelers Face Fingerprints and Jet Lag

[Thomas Shaddack]

On Sun, 3 Oct 2004, J.A. Terranson wrote:

> (1) There are also a number of non-rebar+concrete "walls" in place to keep
> US citizens from leaving;

Please elaborate?

Re: Geopolitical Darwin Awards

[Thomas Shaddack]

On Sun, 19 Sep 2004, James A. Donald wrote:

> I don't recall the American revolutionaries herding children
> before them to clear minefields, nor surrounding themselves
> with children as human shields.

Using children to clear minefields has its logic. They are often not heavy 
enough to trigger the mine, and they often fear less, which both makes 
them more successful and more willing to do the job.

Re: potential new IETF WG on anonymous IPSec

[Thomas Shaddack]

On Thu, 16 Sep 2004, Major Variola (ret) wrote:

> At 02:17 PM 9/16/04 -0700, Joe Touch wrote:
> >Except that certs need to be signed by authorities that are trusted.
> 
> Name one.

You don't have to sign the certs. Use self-signed ones, then publish a GPG 
signature of your certificate in a known place; make bloody sure your GPG 
key is firmly embedded in the web-of-trust.

This can be done with certs signed by an untrusted (read: any other than 
the one you operate yourself) CA as well.

For HTTPS, there can be a negotiated standard location and format of the 
certificate signature file, stored in eg. /gpgsigned.xml location; the 
certificate is transported during the SSL handshake, so you can validate 
it within a single HTTPS request for the file.

Similar thing applies for the client certificates and the servers; but 
then the server has to request the certificate signature from somewhere 
else (the location may be specified as an URL in the comment field of the 
client certificate). This should be easy to implement with PHP scripts, if 
Apache is configured to make the certificate visible as an environmental 
variable.

Re: potential new IETF WG on anonymous IPSec

[Thomas Shaddack]

On Wed, 15 Sep 2004, Ian Grigg wrote:

> The whole point of the CA model is that there is no prior
> relationship and that the network is a wild wild west sort
> of place - both of these assumptions seem to be reversed
> in the backbone world, no?  So one would think that using
> opportunistic cryptography would be ideal for the BGP world?

If I remember correctly, the TCP MD5 option field was designed for 
securing BGP traffic, using the shared secret approach.


I was also thinking about "borrowing" this feature for things like 
announcement of additional features, eg. the possibility of opportunistic 
encryption, in eg. the TCP/SYNACK packets. There's space for 16 bytes of 
magic numbers.

Re: Geopolitical Darwin Awards

[Thomas Shaddack]

On Tue, 14 Sep 2004, Major Variola (ret) wrote:

> How about Iran stating that they're messing with UF6, when Israel[1] is 
> a known pre-emptive bomber of Facilities to the East?  That's pretty 
> much tickling the dragon.

Maybe they are playing a different game. They couldn't use the eventually 
produced nukes anyway, without being showered back with the same kind - 
but an entire Middle East crammed full of decently pissed Arabs may be 
well-worth of one lousy sacrificed reactor. A PR campaign with virtually 
guaranteed results is cheap for that price.

> [1] A wholly 0wn3d subsidiary of the US.  Or perhaps vice-versa.

Don't be so harsh on them. "Mutual ownership of controlling stocks" is 
likely to be more accurate description.

Re: anonymous IP terminology (Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from hal@finney.org))

[Thomas Shaddack]

On Sun, 12 Sep 2004, R. A. Hettinga wrote:

> From: Adam Back <[EMAIL PROTECTED]>
> Subject: Re: anonymous IP terminology (Re: [anonsec] Re: potential new IETF
> 
> At ZKS we had software to remail
> MIME mail to provide a pseudonymous email.  But one gotcha is that
> mail clients include MIME boundary lines which are pseudo-random
> (purely to avoid string collision).  If these random lines are
> generated with a non-cryptographic RNG it is quite likely that so
> called unlinkable mail would in fact be linkable because of this
> higher level protocol.

Wouldn't it be relatively easy to regenerate the MIME boundary strings on 
the level of the remailer, and filter the content of the headers? Various 
mail clients have various peculiarities, "fingerprints". Shouldn't the 
remailer be able to break the message down to individual data objects 
(subject, message text, attachments...) and then reassemble them back, in 
a sanitized way?

Re: "Forest Fire" responsible for a 2.5mi *mushroom cloud*?

[Thomas Shaddack]

On Sun, 12 Sep 2004, J.A. Terranson wrote:

> "No big deal"?  Who are they kidding?

A 2-mile wide cloud is WAY too big to be caused by a single explosion, 
unless REALLY big. The forest fire claim sounds more plausible in this 
regard. An existing cloud could be used for masking, though.

But a surface or atmospheric blast would produce a flash plowing through 
the entire EM spectrum; from long-wave radio to microwaves to hard gamma. 
That's something the satellites Up There can't miss even through a smoke 
cloud - at least if they are still operational or replaced by newer ones. 
(Remember the strong flashes of gamma bursts, originally discovered by 
satellites observing the nuclear test ban: 
.) Also a 
disruption of this kind would be perceivable in long range, possibly by 
quite many people.

An underground blast, if not screwed up, wouldn't produce a cloud at all.

However, both surface and underground blast would have a peculiar seismic 
signature. There is a network of both nonproliferation-surveillance and 
plain old scientific seismic stations all over the world. Something like 
that couldn't stay hidden for too long. Remember the day the the Kursk 
submarine became famous; the recording of the double signature, the 
explosion and shortly later following implosion, appeared online in couple 
days (or maybe even hours?) after the Event. It's difficult to imagine a 
true nuclear blast would stay unreported for more than few days. Even if 
it would really be a nuke test and the politicians would want to be quiet 
about it, there are too many subjects outside of the direct US political 
control to either report the measurements or the eventual pressure to not 
report them.

According to CNN, there was also a strong blast reported in the area of a 
missile base. We don't know how strong the blast was, and if it couldn't 
be just a "conventional" explosion, caused by eg. a combination of a 
forest fire and an ammo depot.

There is also a possibility the "senior officials with access to 
intelligence" were injecting media with false information. Remember there 
are many subjects with different agendas here and a little psyops here and 
there is quite common.

Let's not jump on the conclusions yet. Wait 2-3 days, optionally watch the 
traffic in conferences of geologists taking care of the seismic activity 
worldwide and in the vicinity of the area of interest. It's Saturday and 
many people who could know the answers are away from their instruments; 
let's wait what they will find on their screens on Monday morning.

Re: whatever is necessary

[Thomas Shaddack]

On Fri, 3 Sep 2004, Major Variola (ret) wrote:

> Just heard Clinton's going in the hospital to get a heart.

Clinton was a victim of an assassination attempt by junk food.

McQaeda, the cardiovascular terrorist organization endangering the 
Developed World and deemed responsible for millions lives every year, 
didn't issue a statement yet.

Re: gmail as a gigabyte of an external filesystem

[Thomas Shaddack]

On Fri, 3 Sep 2004, Adam Back wrote:

> Don't know anything about EncFS, but you could also use loopback
> encryption on top of gmailfs.  Just make a large file in gmail fs, and
> make a filesystem in it via loopback virtual block device-in-a-file.

According to the shards of knowledge about GmailFS (gained on Slashdot), 
every file write sends the entire file to the Gmail mailbox. So this 
approach would be VERY taxing on the bandwidth. (Besides, even "free" 
resources should be conserved, whenever practical.)

For GmailFS, we need a file-oriented approach, for which the EncFS one is 
perhaps the best of the few ones known to me.

(A workaround could be to modify the loopback driver, so instead of one 
loop file one could use a directory with a suitable number of "clusters" 
of suitable size. Could be useful for the situations where we need a 
filesystem realized on a device allowing file access with coarse 
granularity, without easy random access to file offsets. But I am not sure 
if it is worth the hassle. (Sure is, just find the proper scenario.))

Re: gmail as a gigabyte of an external filesystem

[Thomas Shaddack]

On Sun, 29 Aug 2004, Thomas Shaddack wrote:

> Question for the crowd: How difficult it would be to write a suitable 
> crypto engine as a plug-in module for FUSE itself? Then we could have 
> support for encrypted files on any filesystem accessible through FUSE.
> 
> ---
> http://www.boingboing.net/2004/08/29/turn_gmail_storage_i.html

It seems that there is a solution Out There already, in the form of EncFS. 
See http://arg0.net/users/vgough/encfs.html

Mount the GmailFS as eg. /mnt/gmail, and then mount encfs to eg. 
/mnt/gmailsec with /mnt/gmail as its root.

Voila, problem solved! (At least theoretically. I didn't test it.)

What are your thoughts on EncFS, please?

Related note: Is there a way to encrypt a removable medium, eg. a CD or 
DVD disk, in a way that makes it readable under all major OSs (with the 
required add-ons installed), namely Linux, BSD, and Windows 98/2000/XP? 
The appeal (and a certain disadvantage) of EncFS is its file-oriented 
approach, making it easy to have a portable userspace decoding utility, 
for data access anywhere if you got the password.

Suggestion

[Thomas Shaddack]

I hereby suggest to postpone the flamewars for the winter, when the 
weather brings the need of some spare waste heat.

I thought we're above name-calling here. But perhaps it was just a quiet 
period and the current situation will rectify on its own in couple days, 
as it usually does.

Besides, the recent development around the hash functions is quite 
important to know about.

Re: yes, they look for stego, as a "Hacker Tool"

[Thomas Shaddack]

On Sat, 14 Aug 2004, Major Variola (ret) wrote:

> >Argh. You misunderstood me. I don't want to find hash collisions, to
> >create a false known hash - that is just too difficult. I want to make
> >every file in the machine recognized as "unidentifiable".
> 
> No, I understood this.  In a later post it was brought up that this is 
> essentially watermarking your content with a unique ID, which can be bad 
> for P2P tracing purposes.  So I was suggesting that by using a finite 
> set of 'watermarks' one could avoid essentially embedding a unique label 
> to one's copy of some content, at some cost in Cycles.

We can also periodically "reuniquize" the shared files, in some sane 
period, say every weekend. (That pollutes the shared-files pool with a lot 
of almost-the-same copies, diminishing the advantage of multisource 
download. So perhaps is it better to just use encrypted data storage and 
anonymized P2P network, and keep uniquicity only of the system 
executables?)

> >on their hash (emule, Kazaa(?),...) instead of their file name will
> >consider them a different file, which causes problems with multisource
> >download (though the problem won't be on your side).
> 
> True.  But I've found some manual intervention to be required anyway, 
> sometimes you find a few copies of the same content stored as 
> independent files due to slight differences in naming or truncation.

Yes. However, depending on the system, same files (with the same hash) 
differing only by name will look as a single file (eg. edonkey or WinMX). 
Other systems, depending on the file name only (eg. OpenNap), will show 
files with different names as different, even if identical inside.

> It was disturbing that, as the bottom fell out of telecom, and handsets 
> became commoditized, faceplates and ringtones were highly profitable. 
> Faceplates are at least made of atoms.  There are several lessons there, 
> from economic to sociobiological (if there's a difference), none of 
> which are terribly pleasing in my aesthetic.

Care to elaborate further, please?

> Fortunately the whole PDA vs. cell vs. camera vs GPS vs. smartcard vs 
> MP3 player vs. email-pager etc bat-belt [1] frenzy will resolve in a few 
> years, and perhaps some of the Linux based solutions will not be 
> involuntary citizen-tracking devices and will support privacy of data 
> stored, and in transit, including voice data.  And free ring tones :-) 
> All that's needed is one of the hardware-selling companies to start the 
> process, making money off the atoms, and possibly Sharp's Zaurus (?) 
> already has?

Or buy an Enfora Enabler GSM/GPRS module, add a Gumstix module with 
built-in bluetooth, slap in a suitable display and keyboard, eventually 
add a GPS receiver, and we're set. All features and security modes we can 
imagine, and then some.

Preventing spatial tracking is difficult though, as we're dependent on the 
cellular network for staying online. Though if the given area has wifi 
mesh coverage, it could be easier. (And if the device becomes widely 
popular, the handsets can serve as mesh nodes themselves - but that's a 
song of rather far future.)

> Perhaps there's a biz model in buying a 3-D color prototyping machine 
> for $40K and setting up a custom faceplate biz for the integrated gizmo 
> of the near future. Hmm, with freedom-enabling software being 
> distributed on the side, it sounds like a Heinlein novel...

Why not? :) Isn't the main purpose of science-fiction (at least its 
certain kinds) to be the inspiration for the future?

On the other hand, perhaps it's cheaper to just get a bulk supply of 
"blank" faceplates and hire an artist with an airbrush and a talent.

It's also possibly easier (and cheaper) to make the parts in more 
classical way, eg. by casting them from resin. The rapid prototyping 
machines so far usually don't provide parts that are both nice-looking, 
accurate, and with suitable mechanical properties at once.

> [1] Batman (tm) wore a belt with too many gizmos.  Some widget-fetishist
> friends/early adopters are similarly afflicted.

There is nothing like "too many" gizmos! (Well, you could call such 
situation "almost enough", but never "too many".)

Re: yes, they look for stego, as a "Hacker Tool"

[Thomas Shaddack]

On Sat, 14 Aug 2004, Thomas Shaddack wrote:

> > polymorphic or encrypted, but then they would be in the "unknown" 
> > category, along with user-created files.  And programs :-)  To be 
> > manually inspected by a forensic dude.
> 
> Run a tool for signature changing preemptively, on *all* the files in the 
> system that can be changed without changing their function? Then you have 
> the forest where every tree is marked and the leprechaun is laughing.

BEWARE! You should keep in mind this deals with the problem of well-known 
signatures by making the files globally unique, but it introduces a 
vulnerability by the same mechanism: the files are unique and can be 
linked with you.

You may mitigate this by "reuniquing" the files in every case you are 
giving them away, but you should keep this risk firmly in mind.

Re: yes, they look for stego, as a "Hacker Tool"

[Thomas Shaddack]

On Fri, 13 Aug 2004, Major Variola (ret) wrote:

> Even if you map a particular hash into one of a million known-benign
> values, which takes work, there are multiple orthagonal hash algorithms
> included on the NIST CD.  (Eg good luck finding values that collide in
> MD5 & SHA-1 & SHA-256 simultaneously!)

Argh. You misunderstood me. I don't want to find hash collisions, to 
create a false known hash - that is just too difficult. I want to make 
every file in the machine recognized as "unidentifiable".

> >> These hash-CDROMs are also useful for finding unlicensed software and
> >> music
> >
> >Another reason for making your data unique.
> 
> In that case, yes, although ultimately the RIAA could hire offshore 
> Indians to listen to your stego'd/uniquified Madonna song and identify 
> it.  (Of course, they don't know if you own the vinyl for it... and 
> software can be sold by the original purchaser, too, right?)

The adversary has acoustic fingerprinting software. Even cheaper than 
the Indians.

The signature busting of MP3s has a disadvantage, though: makes their 
sharing back to the P2P pool more difficult, and a lot of programs relying 
on their hash (emule, Kazaa(?),...) instead of their file name will 
consider them a different file, which causes problems with multisource 
download (though the problem won't be on your side).

> Yes something like a Tomlinson (_Big Breach_) sleight of hand with a 
> Psion card is a good idea, as is the microwave oven trash can next to 
> your machine :-)

Or a small propane torch or a lighter (the kind that makes the hissing 
blue high-temperature flame), or even a sticker with magnesium shavings to 
burn through the chip when lit.

> >... and there still is a segment of consumers who think that
> >when it is free, it's worthless)
> 
> And a larger segment which will stick any CD they get in the mail into 
> their bootable drive.. LOL

Didn't realize this. Seems I still overestimate Them the People.

> Sorta like the National Forests... resource of many uses... may as well 
> include a mixmaster payload in that worm :-) which also provides some 
> other overt free benefit like antivirus or anti-helmetic or defrag or 
> game or bayesian spamfilter or chat or screensaver or anon remailing 
> client or free ringtone :-)

Free ringtones. Good attractant these days. I tend to forget about them as 
I tend to shun fancy tones - telephones should have a distinctive ring but 
"distinctive" does not have to mean "orchestral". But apparently there are 
large sets of people who like it. Weird...

Re: yes, they look for stego, as a "Hacker Tool"

[Thomas Shaddack]

On Fri, 13 Aug 2004, Major Variola (ret) wrote:

> Any jpg which looks like noise will be of interest.  And any stego 
> program will make them look at your images (etc) more closely :-)
> 
> Most of the programs they've hashed is so the forensic pigs can discount 
> them. But they would find known-stego tools very interesting. And they 
> would find them, even if renamed, from their sigs; but not if 
> polymorphic or encrypted, but then they would be in the "unknown" 
> category, along with user-created files.  And programs :-)  To be 
> manually inspected by a forensic dude.

Run a tool for signature changing preemptively, on *all* the files in the 
system that can be changed without changing their function? Then you have 
the forest where every tree is marked and the leprechaun is laughing.

> These hash-CDROMs are also useful for finding unlicensed software and
> music

Another reason for making your data unique.

> 
> Osama sez: Always use original images and sounds as stego carriers.

DV camcorders are becoming increasingly popular. Is there any software to 
stego the data into DV streams? Such files are suitable as carriers, as it 
is easy to produce gigabytes and gigabytes of meaningful data from a 
single friend's wedding - which allows even sparse encoding without having 
improbable amount of data.

> And keep your tools encrypted, or on memory sticks you can flush or
> snap with your fingers.

Beware of destruction of memory sticks; as long as the Flash chip is 
intact, even if its casing itself is broken, it is easy for a properly 
equipped lab to get the chip out of the case and bond it to new casing. 
The Flash chips used in the USB disks have serial interfaces, which makes 
the task of connecting them again rather easy, if you have the right toys 
(available for anybody who does eg. thick-layer hybrid circuits).


A neat trick to lower the suspicion-factor for stego in JPEG or video 
could be releasing a closed-source program for Windows as either freeware 
or easy-to-hack (or without the time check at all) shareware (we don't 
want the money here, but we want the people to think it's doing a lot of 
good for them, and there still is a segment of consumers who think that 
when it is free, it's worthless), which is touted loudly for enhancing the 
images. While all it can be doing is to slightly manipulate brightness and 
contrast in the too dark or too light areas, smear or sharpen the image a 
little bit; may be just couple NetPBM tools cobbled together with a nice 
interface added (we'll violate the licence here, but that's a minor detail 
- which can further serve to bring attention to the tool). And, last but 
not least, inserting a steganographed random data into them. May be 
something meaningful, may be just random data, may be perhaps random data 
chunked to packets looking like a GPG-encrypted file.

Put it online, wait until the news are slow, and get some computer 
graphics magazines interested in it, writing articles about it. Perhaps 
run an astroturf campaign, guerrilla marketing. Get it distributed on the 
CDs shipped with them. Even with just fraction of % of the images "in the 
wild" there will be a lot of them looking like stegoed, serving as a 
convenient smokescreen for the "real" ones.

The sheeple don't have to be only a threat. They can be useful, if their 
gullibility is properly exploited.

Re: Forensics on PDAs, notes from the field

[Thomas Shaddack]

On Fri, 13 Aug 2004, Tyler Durden wrote:

> And it seems to me to be a difficult task getting ahold of enough photos 
> that would be believably worth encrypting.

Homemade porn?

Re: Forensics on PDAs, notes from the field

[Thomas Shaddack]

On Fri, 13 Aug 2004, Sunder wrote:

> If you're suspected of something really big, or you're middle eastern,
> then you need to worry about PDA forensics.  Otherwise, you're just
> another geek with a case of megalomania thinking you're important enough 
> for the FedZ to give a shit about you.

In the world of industrial espionage and divorce lawyers, the FedZ aren't 
the only threat model.

Re: Forensics on PDAs, notes from the field

[Thomas Shaddack]

On Thu, 12 Aug 2004, Thomas Shaddack wrote:

> > The NIST CDROM also doesn't seem to include source code amongst its 
> > sigs, so if you compile yourself, you may avoid their easy glance.
> 
> A cool thing for this purpose could be a patch for gcc to produce unique 
> code every time, perhaps using some of the polymorphic methods used by 
> viruses.
> 
> Just adding a chunk of data to make the hash unique will work against the 
> current generation of the described tools. But we should plan to the 
> future, what moves the adversary can do to counter this step.

We can do some in-depth changes of the executable, using the 
"Steganography in executable files" approach described here (and on 
Slashdot) recently. See eg. here: 
http://www.informit.com/articles/article.asp?p=102181&seqNum=6

The difference is we don't want to store anything to the file itself but 
just to change its content without changing its function. We can use the 
Hydan approach, using random data as what to store inside. Adding a 
command
dd if=/dev/urandom count= | $HYDAN_STEGO $exefile
(where $HYDAN_STEGO is the steganography-adding program and $exefile is 
the product of the compilation by an unmodified compiler)
into the makefile of the project could make the signatures unique for 
every compilation. Same applies to installation scripts. As we shouldn't 
trust our tools completely, a suite of suitable test vectors should be run 
afterwards.

This can be used in combination with executable packers (eg. UPX), or some 
wrappers for "copy-protection", which wrap and optionally encrypt the 
executable and refuse to run it when eg. a dongle (which can contain the 
key) is not present in the computer. It doesn't work for copyprotection 
too well, but can slow down the adversary (or making some of their attack 
methods impossible or impractical to use) in other scenarios. If the usage 
scenario is plausible, the deployment of the protection technology may 
"make sense", so its presence won't have to necessarily raise suspicion. 
(We have to always keep in mind that the presence of any given technology 
can be a factor on its own.)

The adversary then has to resort to heuristic analysis of the code 
segments, or hashing data segments, or maintaining sets of characteristics 
of the executables other than the hashes of the complete file (code/data 
segments size, addresses of jumps...), or relying on the strings in the 
file, or other options, all of them more difficult than hashing a file, 
and potentially requiring better-trained forensics people...

Re: Forensics on PDAs, notes from the field

[Thomas Shaddack]

On Fri, 13 Aug 2004, Morlock Elloi wrote:

> > A cool thing for this purpose could be a patch for gcc to produce unique 
> > code every time, perhaps using some of the polymorphic methods used by 
> > viruses.
> 
> The purpose would be that they do not figure out that you are using some
> security program, so they don't suspect that noise in the file or look for
> stego, right?

In better case, this. In worse case, to force the adversary to face an 
unknown, unexpected situation they aren't trained to handle.

> The last time I checked the total number of PDA programs ever offered to public
> in some way was around 10,000 (5,000 ? 100,000 ? Same thing.) That can be
> trivially checked for. Any custom-compiled executable will stand out as a sore
> thumb.

Until a Gentoo-like Linux distro for PDAs appears. Then custom-compiled 
code becomes quite common in that segment of consumers.

Another possible way for wrecking the set of file signatures "in the wild" 
could be releasing a product (which then would have to become popular, so 
it has to be useful) to do a function modifying the executables - may be a 
code packer (flash space is still a premium in the PDAs), may be a 
realtime patcher (for eg. protecting against some generic code exploits), 
in extreme cases may be an otherwise benign trojan or worm.

> You will suffer considerably less bodily damage inducing you to spit the
> passphrase than to produce the source and the complier.

Yes, but the same applies to your colleague. Would you like it to be easy 
for your colleague to betray you?

> Just use the fucking PGP. It's good for your genitals.

Unless the adversary beats the passphrase from your colleague and then 
comes for you.

Don't be so selfish. :)

Re: Cryptome on ABC Evening News?

[Thomas Shaddack]

Can somebody record it in MPEG or DivX, please? :) It's difficult to get 
ABC News across the Atlantic without a dish.


On Thu, 12 Aug 2004, R. A. Hettinga wrote:

> There's a teaser for tonight's 6:30 news about "a wesite that publishes
> pipeline maps and the names and addresses of government employees". The
> horror.
> :-)
> Cheers,
> RAH

Re: Forensics on PDAs, notes from the field

[Thomas Shaddack]

On Wed, 11 Aug 2004, Major Variola (ret) wrote:

> Obvious lesson: Steganography tool authors, your programs
> should use the worm/HIV trick of changing their signatures
> with every invocation.  Much harder for the forensic
> fedz to recognize your tools.  (As suspicious, of course).

It should be enough to do that at the installation time. The adversary in 
this model gets to analyze the file only once, and we want to make sure 
that nobody tampered with the file as a protection against other, more 
"active" threat models. What we want is to have a file and its hash, so we 
can make sure the file content is unchanged, but the hash has to be as 
globally-unique as possible.

> The NIST CDROM also doesn't seem to include source code amongst its 
> sigs, so if you compile yourself, you may avoid their easy glance.

A cool thing for this purpose could be a patch for gcc to produce unique 
code every time, perhaps using some of the polymorphic methods used by 
viruses.

Just adding a chunk of data to make the hash unique will work against the 
current generation of the described tools. But we should plan to the 
future, what moves the adversary can do to counter this step.


Then there's the matching of date/time of the files to "real-life" events. 
Perhaps a countermeasure could be a modified vfat filesystem which 
assigns free clusters randomly instead of sequentially (on a solid-state 
medium fragmentation does not matter), which avoids the reconstruction of 
the file saving order by matching the position of their clusters (for the 
price of making undelete difficult), and an absence of timestamps 
(01-01-1970 is a nice date anyway).

The file delete function in the filesystem driver can be modified to file 
overwrite-and-delete, for the price of higher wear of the FlashEPROM 
medium.

Linux-based (and open-architecture in general) PDAs should offer much 
higher thug-resistance.

Re: Michael Moore in Cambridge (download speech)

[Thomas Shaddack]

On Tue, 10 Aug 2004, Pete Capelli wrote:

> Being still currently undecided myself (although living in one of the
> 32 or so 'pre-ordained' states) I found this speech to be "most
> cynical, opportunistic, divisive, and un-American" ones I've listend
> to in awhile.

Define "un-American", please?

Re: NSA Overcomes Fiber-Optic and Encryption

[Thomas Shaddack]

On Mon, 9 Aug 2004, John Young wrote:

> Excerpt below from a Baltimore Sun article of August 8, 2004.
> Some of it could be true, but.
> http://cryptome.org/dirnsa-shift.htm

I think the correct title would be "sidesteps" instead of "overcomes".

It's a fundamentally different way (though the result is the same).

Re: The Turncoats on Niihau Island

[Thomas Shaddack]

On Tue, 10 Aug 2004, R. A. Hettinga wrote:

> The Turncoats on Niihau Island
> Michelle Malkin (back to web version) | Send
> ...
> The Haradas were neither radical nationalists nor professional spies. They
> were ordinary Japanese-Americans who betrayed America by putting their
> ethnic roots first. How many other Japanese-Americans-especially on the
> vulnerable West Coast-might be swayed by enemy appeals such as
> Nishikaichi's? How many more might be torn between allegiance for their
> country of birth and kinship with Imperial invaders?

The ethnicity or religion or political affiliation are not the only risk 
factors. What about something so plain and simple as money? Would the 
author advocate rounding up the needy and the greedy?

Have not enough money? You're a suspect. Have too much money? You're a 
suspect too. Now imagine the fun if these two categories would overlap...

Re: On what the NSA does with its tech

[Thomas Shaddack]

On Wed, 4 Aug 2004, Hal Finney wrote:

> As you can see, breaking 128 bit keys is certainly not a task which is
> so impossible that it would fail even if every atom were a computer.
> If we really needed to do it, it's not outside the realm of possibility
> that it could be accomplished within 50 years, using nanotech and robotics
> to move and reassemble asteroids into the necessary disk.

There are easier targets than the symmetric cipher algorithm itself.

You may aim at RSA, try to break through the factorization problem, or 
find another weakness in it. Same for other algorithms of this class.

You may aim at the passphrase, as several other people suggested.

You may use nanotech to compromise the hardware, and/or to intercept the 
data. This includes "eating and duplicating" chips, including key storage 
tokens; just go layer after layer and rebuild it (or create its "virtual" 
image) including the levels of electric charge in the memory cells. How to 
design a token that would be resistant to nanoprobes? (Perhaps by 
equipping it with an "immune system" of nanoprobes of its own?)



Quantum computers may be the way to break factoring-related algorithms.

Nanotechnology can bring many ways for physical compromising of the 
targets and their vicinity (the "fly on the wall" attack).

The impracticability of breaking symmetric ciphers is only a comparatively 
small part of the overall problem.

Terrorists wear neckties.

[Thomas Shaddack]

I don't worry about car bombs nor hijacked airplanes. I have better chance 
of being killed in a standardized ISO-compliant CE-marked car crash than 
getting into mere visual contact with a bomb blast.

On the other side, the streams of bureaucrap the Hellhole also known as 
Brussels spews every day are filling my heart with genuine fear.

Forget about turbans. Real terrorists wear neckties.

Re: X-Cypher, SIP VoIP, stupid propriatory crapola

[Thomas Shaddack]

On Thu, 29 Jul 2004, Dave Howe wrote:

> Thomas Shaddack wrote:
> > Sounds like an anonymous Diffie-Hellman session key, wrapped in marketing
> > bullshit. Usable, but susceptible to MITM.

> Unless I am reading this wrong, it is much, much worse than that - it seems to
> say that, unless you are running your own server (which requires a DNS entry
> and server rights, etc), the session key is being generated at the central
> server and *issued* to the two parties - with all the third party compromise,
> LEAK order problems and sheer poor design issues that implies.

Didn't thought about this. Noticed the "generated by server" thing, but 
thought it'll be a local process collecting entropy from some hardware 
source. Yes, your Honor, I admit I am guilty from assuming lack of 
stupidity on the vendor side. :(

> SIP *has* a crypto negotiation field in the protocol - why aren't they using
> that, instead of "rolling their own"?

Perhaps because they don't want to make a really secure system, aren't 
aware about this possibility, were politely told to not use it by some 
Third Party, don't know how to do it this way...?

Maybe it could be a good idea to ask them.

Re: X-Cypher, SIP VoIP, stupid propriatory crapola

[Thomas Shaddack]

On Wed, 28 Jul 2004, Dave Howe wrote:

> Particularly disgusted by the last paragraph

> | With encryption comes the problem of either managing public/private
> | keys, which must be kept secret, or the annoyance of transmitting a
> | secure key to a remote party over other secure methods. X-Cipher
> | eliminates these issues. No public/private keys exist to guard and keep
> | safe and worry about theft and reuse. Each conversation through
> | X-Cipher gets a unique secure key generated by an X-Cipher server using
> | strong Crypto random safe algorithms.

Sounds like an anonymous Diffie-Hellman session key, wrapped in marketing 
bullshit. Usable, but susceptible to MITM.

Re: Why there is no anonymous e-cash

[Thomas Shaddack]

On Mon, 19 Jul 2004, James A. Donald wrote:

> As I predicted, transactions are increasingly going on line.
> 
> And as Hettinga predicted, the more anonymous and irreversible the 
> transaction service, the cheaper and more convenient its services.  
> All happening as predicted.
> 
> So why don't we have anonymous chaumian cash by now?

For anonymous cash systems outside of the government control, we first 
need generic unofficial cash systems.

I just stumbled over two different alternative "cash" systems already in 
use, and there are hundreds more:

http://www.calgarydollars.ca/faq.html
http://www.ithacahours.com/

There are many other kinds of currencies; some of them are even 
exchangeable for "real money", eg. casino chips.

As we can see from the aforementioned examples, the requirement for 
convertibility between the alternative currencies and the "mainstream" 
ones is not absolute.

My guess is that the time for Chaumian cash didn't come yet; but the signs 
are already on the sky.

My suggested course of action is to not worry about when it happens, and 
spend the time working on implementations. It's only matter of time when 
the already existing systems will feel the need to go electronics; they 
are usually local, so the physicality disadvantage of tangible material 
"certificates" like pieces of paper or metal isn't too annoying, but it is 
a limitation neverthless. That is possibly the best starting point; a set 
of proof-of-concept implementations is probably necessary for further 
expansion. This will also seed the market, and get the people used to the 
technology - and, if it turns out useful for them, demanding it elsewhere, 
further driving its expansion.



> Because, the more anonymous and irreversible its services, the more 
> fraudsters use it to convert other people's bank accounts, obtained 
> by phishing, into usable money.

I suppose the countermeasures against this exist. (That the banks 
habitually don't deploy them is another thing.)


> Why don't we have anonymous e-cash? - because IE and outlook express 
> are full of massive security holes, and because people are idiots.  
> Observe Tim May, who mistook e-gold phishing spam mail for the real 
> thing.  Well, not so much that people are idiots, but that we still 
> have not got a satisfactory security model that adequately 
> accommodates human factors.

Why aren't we working on it already then?

Re: Email tapping by ISPs, forwarder addresses, and crypto proxies

[Thomas Shaddack]

On Thu, 22 Jul 2004, Major Variola (ret) wrote:

> My point is only that they will be killed should they leak their
> actual capabilities.

Well... I am reading a book about intelligence now. Specifically, "Ernst 
Volkman: Spies - the secret agents who changed the course of history". 
Amusing book; describes many ways of intelligence fieldwork, most of them 
pretty lowtech. Eg, using business representatives as business/technology 
spies (as eg. a skilled steelworker can assess the capacity and capability 
and current processing of a factory quite at a glance, and he's often let 
in during contract negotiations), using pretty women to lure officers into 
honeytraps... or, recruiting young pretty men to seduce the not exactly 
pretty old maids who so often work as secretaries in important places.

You don't need a *LOT* of money to pull smaller-scale tricks of this kind. 
Also, using "amateurs", private enterpreneurs in the arts of burglaries, 
safecracking and other relevant areas, instead of "governmental" 
employees, poses a counterintelligence advantage that these recruits are 
unknown to the adversary (and to most of your side too, so there's less 
chance somebody will be caught or changes sides and squeaks on them).

There are many ways to get access to even pretty sensitive info. Patience 
and persistence and plethora of approaches are important here.



> >Undersea taps are hard.  No matter how you figure it.
> 
> You think subs are just toys?

"Hard" doesn't imply "impossible". It however hints on the likely success 
rate.


> >The actual intel/counterintel guys make shit for money.

Depends on whom. Often the money are the main motivation. Of course, your 
own country won't pay you as well as the other one, and will try to appeal 
to your "patriotism" like a bunch of cheapskates - it's better to be a 
contractor.

> What I meant was, Ames and that FBI dude Hansen (sp?), at least the KGB 
> got Ames' wife as part of the package, whereas the FBI CI dude let his 
> wife off as part of the deal he cut.  Nice xian that he was, he was into 
> strippers.
> 
> All under $2e6, all capable of reading their own records.  Go figure,
> eh?

And many of them disclosed their colleagues when politely asked.

But a big truth remains here - SIGINT and COMINT aren't everything, often 
a drop of HUMINT is the missing secret sauce.


Q: What's the difference between a secret service director and a gardener?
A: None. Both have their turf full of moles.

Low-cost thermal/multispectral imaging via mechanical slow-scan TV

[Thomas Shaddack]

Thermal imaging is a very powerful and very cool technology with many many 
applications in both security and engineering. However, the main obstacle 
for its wider usage in civilian sector is very high cost of the 
microbolometer array sensors.

However, there are affordably cheap remote thermometers on the market, 
using a thermopile or bolometric sensor, which can be considered to be the 
equivalent of a single-pixel array.

In the very beginnings of image transmission, there were various 
technologies being used, many of them using a single-"pixel" optical 
sensor and a mechanical scanning device - a spinning mirror, Nipkow's 
disk, etc..

Can this approach be used in combination with a thermopile sensor? The 
result could be a potentially quite cheap slow-scan thermal imager. 
Because of the lower energy radiated in far-infrared and longer reaction 
time of the sensors, we would have to have much slower scanning speed, not 
allowing real-time imaging, but still enough for engineering purposes, eg. 
finding thermal leaks of buildings or overheating parts on the boards or 
in power installations.

One possible construction is a two-axis polar mount, allowing the 
directional sensor to be aimed in any direction within a range of vertical 
and horizontal angle (eg. a camera tripod with two servos). This would 
have the advantage of being a generic base for any slow-scan multispectral 
imaging device - instead of a directional thermopile use a directional 2.4 
GHz antenna, and scan the city from a roof or a hilltop for the access 
points. (Or use 0.9/1..8/1.9 GHz, and look for cellular towers. Etc.) 
Position the device, set the pixel exposition time, set the angle range 
and step, run the "exposition".

What do you think? Opinions, comments?

Re: Texas oil refineries, a White Van, and Al Qaeda

[Thomas Shaddack]

On Tue, 20 Jul 2004, Justin wrote:

> HOUSTON (Reuters) - Law enforcement officials said on Monday they are
> looking for a man seen taking pictures of two refineries in Texas City,
> Texas.

How difficult it is to wait for a sunny day, wire a digital camera to take 
two pictures per second with very short exposition time, ducttape it on 
the dashboard or at the side or the back window in suitable angle, and 
then drive by in normal speed? If you screw up the angle, you can do it 
again (and again, and again...), because nobody pays attention to the 
"normally" behaving vehicles.

That way, no suspicion is ever aroused.

Or, use a big-lens camera from long distance.

The person in question was just somebody with a weakness for industrial 
architecture.

Cheap TDR for fibers?

[Thomas Shaddack]

The laser diodes used in eg. CD players have a feedback photodiode, 
sensing the laser's optical output.

If the lasers used for optical fibers have similar mechanism too, and if 
the diode is sensitive to the light coming to it not only from the chip 
but also from the fiber itself, and can react quickly enough with high 
enough sensitivity, maybe it could be exploited.

In chosen moments, we could then send a short pulse of laser light into 
the fiber, then watch the signal from the feedback diode, what gets 
reflected back from nonhomogenities on the fiber. This would give us the 
distances of all the splices and connectors, and let us know immediately 
(if the test is performed eg. once per 5 seconds or with similar short 
period) that there is an attempt to compromise the line underway. 
Comparison of snapshots from longer periods apart could also serve to find 
deterioration of the signal path before it results in failure.

The advantage of this approach, if possible, is the ability to add the 
functionality without having to modify the optical transceivers 
themselves.


It sounds too good to be true, so it probably won't work, but I may be 
wrong...

Re: Secure telephones

[Thomas Shaddack]

On Sun, 18 Jul 2004, Bill Stewart wrote:

> If you're trying to build a usable cellphone,
> you've got much more stringent design criteria than a deskphone.

I am painfully aware of it.

> You've got packaging requirements that force you into
> serious industrial design if you want something pocket-sized
> with good battery life, plus you've got to implement all the
> cellular interface features.

Or use the off-the-shelf modules for industrial applications that already 
do it, and add some glue logic.

> If you're willing to build a backpack-phone, that's a lot simpler,
> because you can use a laptop with a
> [pick-your-favorite-cellular-data-standard] card
> and either a wired headset or a Bluetooth frob for a BT headset.

Check the Gumstix and the Enfora Enabler specs. The first is the 
equivalent of a grossly stripped-down laptop (80x20x6 mm, few mA sleep, 50 
mA command-wait, 250mA full power w/o Bluetooth), the second one is the 
equivalent of a comm card (GSM/GPRS, 50x30x3 mm, tri-band 5mA standby). 

The laptop approach is good for prototyping, though.

> I'm not aware of any cellular data cards in PDA-usable format
> (unless you've got a PDA big enough for PCMCIA),
> but you could take a GSM etc. phone with a wired interface to a PDA.

I'd try the Enfora module in that case. RS232 for data and control, and 
analog I/O for voice.

The PDA approach definitely has its merit.

Re: Secure telephones

[Thomas Shaddack]

On Sat, 17 Jul 2004, Steve Schear wrote:

> How about building a secure cell phone using GnuRadio as a core? That way you
> have maximum control afforded by the protocols.

Several reasons valid at this moment (though I suppose (and hope) the 
situation will improve in next couple years).

There is no available implementation for the low-level GSM protocols. 
Doing it from scratch looks like a royal bitch.

The ADC/DAC chips for the required bandwidth are AWFULLY expensive. (I'd 
be happy if proven wrong here. (Well, I'd be happy if proven wrong in 
other two arguments too.))

The required processing power (and the related power (and cooling) 
consumption) is impractically high.

But principially it is a very good idea, whose time will hopefully come 
soon.

Re: vacuum-safe laptops ?

[Thomas Shaddack]

On Sat, 17 Jul 2004, Tyler Durden wrote:

> Sorry to need educating once again, but I had assumed can-shaped capacitors
> were gone from laptops in lieu of surface mount. Anyone know? (I don't own a
> laptop.)

The can caps can be surface-mounted as well. The leads then look 
different, but the inside is still the same: a metal can with etched 
aluminum strips and an insulator soaked with electrolyte. The magic smoke 
they are filled with also has the same color and smell as their non-SMD 
predecessors.

See also http://www.elna.co.jp/en/ct/c_al01.htm for brief description of 
liquid-electrolyte aluminum capacitors.

There are also some more modern constructions, where the electrolyte is 
solid-state. (The tantalum capacitors, which are more common in SMD form 
than the aluminum ones, use MnO2 as electrolyte and Ta2O5 as insulator. 
The added advantage here is that during a breakdown, the MnO2 layer 
locally overheats and is converted to less conductive Mn2O3, which causes 
the breakdown to "heal". Similar mechanism is used in capacitors with 
solid-state plastic electrolyte.)

I suppose the solid-state caps could be much more reliable in the 
conditions of rapid pressure changes, if they won't have moisture or air 
trapped inside their construction.

Re: vacuum-safe laptops ?

[Thomas Shaddack]

On Fri, 16 Jul 2004, Major Variola (ret) wrote:

> Um, even the small form factor PC on a board the size of your palm may 
> still rely on caps in the power supply that don't handle 760 to 0 mm 
> Hg/min so readily.

However, if you use a low-power board, you have less current to filter the 
ripples from, so you need smaller caps, which offers you more options. You 
can also replace the caps in the power supply for vacuum-resistant types, 
for the price of some soldering.

> Otherwise, there are many small PCs on a card if you look into the 
> embedded marketplace.  Complete with solid state disks, etc. COTS.

Do you know some worth of being refered to, if possible low-cost? The 
situation on the market is changing so fast it's difficult to keep track.

> perhaps anon actually wants to run M$ in a low pressure environ.
> Perhaps that's why he's anonymous :-)

Maybe it's agent of Microsoft looking for expanding the market to space! 
(Blue sky instead of blue screen?)

> My guess is regular ole airplane takeoff, but its not quite 0 torr
> at 35Kfeet, and I *think* the cargo part is pressurized, lest
> Fido suffocate.

Also, a lot of cargo can be susceptible to lower pressures. Eg, the 
mentioned capacitors could be popping. So some overpressure during the 
flight has to be maintained there.

> And while a SAM would be a great science fair project, you don't go 
> above that limit.  Perhaps anon will be a space tourist, wanting to take 
> notes, on something heavier than a PDA+keyboard.

In that case, I'd suggest to build it as a wearable computer, integrated 
into the space suit.

> I once TA'd at a UC, one advanced ugrad had a project for an atmospheric 
> science prof building a board for the nose of a spyplane, to sample the 
> air.  (For ozone, not nucleotides.  No, really.) He was interested in 
> vibration problems; I told him to take his proto board on an offroad 
> trip in his car to shake out the moths.

Wise. :)

> Am not sure that epoxy cover makes a difference, the board manuf. go to 
> lengths to avoid air pockets under traces, the ICs themselves fairly 
> (albeit not guaranteed) encapsulated in an epoxy mix.

Sealing the boards in resin, under lowered pressure, could possibly help; 
the pressure of the atmosphere would be replaced by the pressure of the 
resin. Another option could be mounting the device into a hermetically 
sealed case, filled with eg. silicone oil for easier heat transfer.

Re: FIPS chassis/linux security engineer?

[Thomas Shaddack]

On Sat, 17 Jul 2004, Eric Murray wrote:

> For a seperate project, does anyone know of a small linux-ready/able
> box with ethernet?
> Gumstix looks cool but I need hardwire networking.

Soekris, .
PXA255, 

Are there more, and/or better?

Re: vacuum-safe laptops ?

[Thomas Shaddack]

On Fri, 16 Jul 2004, Major Variola (ret) wrote:

> >Does anyone *know* (first or second hand, I can speculate myself) which
> laptops, if any, can safely go to zero air pressure (dropping from 1 atm
> to 0 in, say, 1 minute.)
> 
> Sorry so late ---but your can-shaped capacitors might not handle the
> rapid depressurization so well.

Perhaps it's time to challenge the introductory assumption. Why a laptop? 
There are many various embedded computers available on the market, eg. the 
one from . (Question for the crowd: anybody knows 
other comparable or better Linux-ready affordable embedded computer 
solutions?) You may like to take such module and seal it in resin in order 
to shield it from the pressure changes (question for the crowd: would it 
really work?). Use memory card instead of hard drive; you don't want 
moving parts that depend on air density. The smaller size and lower power 
consumption than a laptop has makes many issues, from cooling to powering, 
much easier; vacuum-proofing and testing of the assembly is potentially 
simplified as well.

I'd also be cautious about the fluorescent tubes for the displays, the 
glass won't necessarily have to withstand the rapid change in air 
pressure. The LCDs themselves consist from two layers of glass with a 
electricalyl-sensitive light-polarizing liquid between them, make sure it 
won't have tendency to boil or vaporize in vacuum.

Optionally, for unmanned operation, do without the display completely. For 
manned operation, use something like the head-worn see-through 
 display, located in the operator's 
pressure suit, and connect it to the computer by a suitable wired or 
wireless connection.

If the system has to go beyond the reach of the atmosphere, you would like 
to use some sort of radiation shielding, or use a redundant assembly with 
several computers working in parallel, compensating lower reliability 
(silicon-on-insulator chips are difficult to find in off-the-shelf 
setting) with redundancy. You may also prefer to keep critical systems 
working on lower frequencies, with older-design parts, using bipolar 
transistors instead of CMOS (which tends to trap charged particles in the 
insulator layers of the gates, which shifts the gate threshold voltage), 
and chips with larger structures (so the ionization traces of particles 
won't affect the chips that much). Protect the content of the memories - 
large arrays of rad-sensitive elements - with ECC codes. GaAs is also more 
radiation resistant material than silicon. Again, combine rad-hard design 
with redundancy for best results.

Cooling is a royal bitch. You can't use anything but radiation cooling. I 
think satellites use a neat trick with pipes containing a wick soaked in a 
suitable liquid, eg. some freon. The liquid is vaporizing on the hot end 
of the pipe, condensing on the cold end, and soaking back to the hot end 
by capillary forces; this is used to bring the heat from the power parts 
and the sun-facing side of the satellite to the dark side of the 
satellite, from where it radiates to space. (Question for the crowd: Can 
thermal imaging be used for scanning the sky for low-orbit satellites? 
Other question for the crowd: How suitable would be this wick-in-a-tube 
approach for "ground-level" computers, could it increase the efficiency of 
heat transfer from the CPU chips to the wings of the heatsinks? Eg. for 
the purpose of having the computer sealed in an RF-shielded enclosure, 
with the heatsinks being part of the case, which could eliminate the 
cooling air inlets?)

Secure telephones

[Thomas Shaddack]

Pondering construction of a secure telephone. (Or at least a cellphone in 
general. The user interfaces and features available on virtually all the 
mass-market phones suck, to put it very very mildly, not even mentioning 
that there's no access to their firmware (so no chance of audit), poor or 
no support for SSL (while running HTTP through the operator's proxy), and 
typically no possibility to run more than one Java applet (or other 
program) at the same time. A combination of a GSM/GPRS module with a 
suitable embedded Linux-running computer could be the right solution.)


The easiest way is probably a hybrid of telephone/modem, doing normal 
calls in "analog" voice mode and secure calls in digital modem-to-modem 
connection. The digital layer may be done best over IP protocol, assigning 
IP addresses to the phones and making them talk over TCP and UDP over the 
direct dialup. (We cannot reliably use GPRS, as the quality of service is 
not assured, so we have to use direct dialup. But we can implement "real" 
IP later, when the available technology reaches that stage.)

Once we have the phones talking over IP with each other, we can proceed 
with the handshake. I'd suggest using OpenSSL for this purpose, as it 
offers all we need for certificates and secure transfer of the key. Then 
use UDP for the voice itself, using eg. stripped-down SpeakFreely as the 
engine. So during the call, two connections will be open over the IP 
channel: the command one (SSL-wrapped TCP, for key and protocol handshake, 
ensuring the identity of the caller, etc.), and the data one (a 
bidirectional UDP stream). As the command connection should be silent for 
most of the time, a 14k4 modem should offer us enough bandwidth for 9k6 
GSM codec, even with the UDP/IP overhead.

The problem is with the calls themselves, determining if they have to be 
connected as secure or as insecure.

For landlines, it's easy; we can hold the line open while switching the 
modem between voice and data modes, even if we'd have to do it the 
"hardcore" way with a relay and a 600-ohm resistor connected to the phone 
line during modem hangup. We then can freely alternate between voice and 
data, starting in voice and getting the telephones negotiate over "analog 
sound" using some sequences of beeps, like during the time of acoustically 
coupled modems. We need just few 100s bps to tell each other that we both 
support secure call, and that we want to switch to it.

However, the cellphones pose a much worse problem. The voice/data call 
type is determined at the connection time, and as far as I know, can't be 
changed on-fly. So we would have to have the desired call mode specified 
in the phone's addressbook (with eventual secure mode advertising through 
the mentioned beep sequence when in insecure mode, and eventual automatic 
or manual redial in secure mode). Does anybody here know if there is a 
workaround available for this? How does the Siemens crypto-phone 
 solve this?

It is possible to place data calls from a GSM phone. But it is possible to 
RECEIVE the data calls on it? Can I connect a cellphone to a laptop and 
have a dial-in server?


A workaround here could be exploiting the always-on properties of GPRS (if 
the Enfora modules offer GPRS simultaneously with GSM calls, it could 
provide a lot fo advantages), and use eg. Jabber as a messaging platform 
(overcoming the difficulties with secure SMS messaging), and optionally 
also for secure call negotiation, serving here as a control connection.


A nice feature could be a phone-located voicemail (won't cover the 
situations when the phone is outside of the network reach, but could be 
handy for the situations where the phone is just told to not ring). The 
advantages would be the possibility of the voice being transported in 
secure mode, and the possibility of encrypting the messages in storage. 

Another feature, that could make the device rather attractive in some 
demographics, is the possibility of having the phonebook stored encrypted 
on the handset, inaccessible without a PIN, or not located there at all, 
stored remotely. Yet another advantage, useful for closed groups, is the 
possibility of using Jabber UIDs dynamically mapped to phone numbers, 
allowing the users to swap the handsets, bringing a bit of deniability 
into the location tracking.


The modularity of the design should allow low degree of lock-in to the 
vendors and networks; other modules than Enfora can be used for different 
standards, Enfora produces tri-band (and even quad-band, adding 850 MHz to 
the mix) ones for both US and EU/AU/NZ markets, the control computer 
should be exchangeable for any other kind, with just minor tweaks in the 
software itself. Openness of the design should allow the implementation of 
other emerging secure comm standards, including but not limited to Skype.
Various message-anonymizing tricks could be also done, using 
mixmaster-style forward

Re: Mexico Atty. General gets microchipped (fwd)

[Thomas Shaddack]

On Tue, 13 Jul 2004, J.A. Terranson wrote:

> Forwarded for amusement
> http://www.cnn.com/2004/WORLD/americas/07/13/mexico.chip.reut/index.html
> Mexico attorney general gets microchip implant

Politicians getting RFIDs.

Will it spur a new generation of smart roadside bombs, landmines, and 
perhaps homing missiles?

1. Get the politico's ID.
2. Release a tiny unmanned drone with a small shaped charge.
3. Let it fly over the city or a highway, patroling patiently, drinking 
   the nectar of the sunshine with the panels of its wings, occassionally 
   pinging the ground below.
4. Wait until it hears the target response, then aims to the target using 
   the RFID's response signal the way tracking radars do, falling down for
   a suicide kill, not dissimilar to a beast of prey.

...then a counter-technology appears and the cycle will repeat again.

Re: Bumazhkas

[Thomas Shaddack]

On Tue, 13 Jul 2004, Harmon Seaver wrote:

> > Bumazhkas? I thought I was pretty familiar with most weapons of the world,
> > but not Bumazhkas. What calibre are they? I've always liked those CZ Model 52
> > pistols and Model 32 subguns in .30Mauser. Loaded hot with a teflon coated
> > bullet they should punch thru armor well. 
> > 
>Whoops, that should be "Model 23", not model 32. The 23 - 26 series from
> whence the Uzi got it's basic design, IIRC.

Bumashkas belong between the highest-caliber weapons of the 
bureaucracy-centered governments. You don't want to meet the adversary 
armed with them. They are deadly and should be banned.

("Bumazhka" is a Russian word for "form" or "paper". The way I use it 
should invoke the associations to Soviet-style bureaucracy, requiring a 
stamped permission for just about everything.)

Re: USA PATRIOT Act Survives Amendment Attempt

[Thomas Shaddack]

On Sat, 10 Jul 2004 [EMAIL PROTECTED] wrote:

> >But we have a psychological mechanism here; many people tend to be 
> >"tough" when not under direct threat. Then they implement the 
> >mechanism. Then years flow by. Then the prosecutors come. But by then 
> >it is too late to cooperate. They are doomed (though that depends 
> >largely on the available lawyers), but it can save the ones they were 
> >protecting.
> 
> The mechanism Steve suggested probably needs to be applied before you ever see a 
> court order.

That's a matter of course. At the moment the Men with Bumazhkas come, it's 
too late to act.

When the short circuit happens, it's too late to install the breakers.

> Actually, frequent prosecutions could work to the advantage of a select 
> few who choose to become martyrs.  Since it would make it much more 
> likely supplicants would be called upon.

Please explain this thought?

> I posted a few months back offering an alternative to religion in 
> recruitment: the terminally ill.

That's not good for this purpose; their lifetime is too short.

Re: USA PATRIOT Act Survives Amendment Attempt

[Thomas Shaddack]

On Fri, 9 Jul 2004, Steve Schear wrote:

> This may best be accomplished by placing the data offshore and empowering the
> db operators with some non-repudiatable right of disclosure (especially under
> duress of a warrant).

This may be impractical in some cases.

> Some months back I discussed a procedural methodology where patrons could find
> out if their records hand been accessed in a way that circumvented court
> orders.  I was told that it might work but that frustrated prosecutors might
> press charges of conspiracy before the fact to evade lawful orders that
> 'might' be issued, even if the defendant had no reasonable expectation that
> this might occur.

But we have a psychological mechanism here; many people tend to be "tough" 
when not under direct threat. Then they implement the mechanism. Then 
years flow by. Then the prosecutors come. But by then it is too late to 
cooperate. They are doomed (though that depends largely on the available 
lawyers), but it can save the ones they were protecting.

It seems that, by the prosecutor logic, just about any comsec improvement 
you implemented may be viewed as a conspiracy, including but not limited 
to secure email.

I am not happy to say this, but can we ever hope for designing any kind of 
secure infrastructure without some nodes having to win the martyr lottery?


...speaking about martyrs... I am just watching a TV document about cults. 
Maybe we could piggyback on religion and use some kinks within Christian 
doctrine, selected for having wide user base within Western civilization? 
Eg, finding a believable and theologically coherent explanation how 
operating a Darknet node helps undermining the reign of Satan (a voice 
suggests me that the Book of Prophecies, or how that horsemen thing is 
called, could contain enough of material to build on)? That could provide 
a decent amount of node ops using existing infrastructure of likely-minded 
religious organizations. Faith is a big motivation for undertaking risk, 
and while Westerners currently tend to be less radical than 
Middle-Easterners, this kind of mission is far from suicidal.

But one of the voices in my head just told me that shared MP3s would bring 
in more people with less effort...


> "The law is an ass."
> -- Charles Dickens

Maybe because most of it comes out of ass-holes?

Re: USA PATRIOT Act Survives Amendment Attempt (fwd from brian-slashdotnews@hyperreal.org)

[Thomas Shaddack]

On Fri, 9 Jul 2004, Steve Schear wrote:

> Quite a few book stores (including the local Half-Priced Books) now keep no
> records not required and some do not even automate and encourage their patron
> to pay cash.  In California book sellers to such used/remaindered stores must
> identify themselves for tax purposes.

The Patriot gag orders lead me to a thought.

Is it possible to write a database access protocol, that would in some 
mathematically bulletproof way ensure that the fact a database record is 
accessed is made known to at least n people? A way that would ensure that 
either nobody can see the data, or at least n people reliably know the 
record was accessed and by whom?

When somebody comes with a paper and asks for the data, the one currently 
in charge of the database has to give them out, and may be gag-ordered. 
However, when way too many people know about a secret, which the protocol 
should ensure, it's better chance it leaks out, and less likely to 
identify the one person responsible for the leak, who could be jailed 
then. Especially when at least one of n is outside of the reach of the 
paws of the given jurisdiction.

The question is this: How to allow access to a specific file/db record in 
a way that it can't be achieved without a specified list of parties (or, 
for added system reliability, at least m of n parties) reliably knowing 
about who and when accessed what record? With any attempt to prevent the 
parties from knowing about the access leading to access failure?

Note a peculiarity here; we don't ask for consent of the parties (that 
would be a different threat-response model), we only make sure they know 
about it. (We can deny the access, when at least (n-m)+1 parties refuse to 
participate, though.)

Re: Querying SSL/TLS capabilities of SMTP servers

[Thomas Shaddack]

It fails on hotmail.com; my script has problems there as well (and with 
couple others, the cure seems to be adding delays between the lines sent 
to the server; it makes the program slow, but more reliable).

In my case I added "-i 3" to the netcat options. Isn't a panacea, but 
helped in most cases. In the rest, I have to resort to telnet.

Thanks a lot. Seems I have to learn perl. Looks powerful.


On Thu, 8 Jul 2004, Justin wrote:

> On 2004-07-08T17:50:57+0200, Thomas Shaddack wrote:
> > I cobbled up together a small bash shell script that does this. It lists 
> > the MX records for a domain, and then tries to connect to each of them, 
> > issue an EHLO command, disconnect, then list the output of the server, 
> ..
> 
> Or, in perl... though I wonder if there's a way to get capabilities with
> Net::SMTP.  Might make this cleaner.
> 
> 
> #!/usr/bin/perl
> 
> use IO::Socket;
> use Net::DNS;
> 
> for ($i = 0; $i <= $#ARGV; $i++) {
> my @mx = mx($ARGV[$i]);
> foreach $record (@mx) {
>   my $hastls = 0;
>   my $mhost = IO::Socket::INET->new (
>   Proto => "tcp",
>   PeerAddr => $record->exchange,
>   PeerPort => "25",
>   Timeout => "10"
>   );
>   print $mhost "EHLO I-love-my-country.whitehouse.gov\n";
>   print $mhost "QUIT\n";
>   while (<$mhost>) {
>   if (/STARTTLS/) {
>   $hastls = 1;
>   last;
>   }
>   }
>   print "$ARGV[$i] " . $record->preference . " " . $record->exchange;
>   print $hastls ? " adv-tls\n" : " no-tls\n";
>   close $mhost;
> }
> }
> 

Re: [IP] Hi-tech rays to aid terror fight

[Thomas Shaddack]

On Thu, 8 Jul 2004, Major Variola (ret) wrote:

> 5. One could call terahertz "hard RF"  in same way that hard x-rays
> bleed into soft gammas.  But calling anything "hard" implies danger,
> and we mustn't scare the proles.  Perhaps soft IR is better.

Technically, it's closer to soft IR. If I remember correctly, terahertz 
detectors are closer to bolometers than to antennas.

However, "hard microwaves" could be good (or bad, depending on your side 
of the chessboard) name for psyops purposes.

RE: photodisc search (was Re: BOUNTY BEAR is Faster ...)

[Thomas Shaddack]

A big database of images with metadata can be used to train a neural 
network (or other suitable AI approach) to recognize unknown images.


On Thu, 8 Jul 2004, Tyler Durden wrote:

> 
> Yeah, but this is a metadata search, correct? Seems to me Our Protectors(TM)
> are probably able to search a vast database of images themselves. In other
> words, go look for details they hadn't previously thought of as being
> important (and hence were not available in metadata). Given high-density CCDs
> and real cheap storage, these details may be very minute, or perhaps small+far
> away.

Querying SSL/TLS capabilities of SMTP servers

[Thomas Shaddack]

I cobbled up together a small bash shell script that does this. It lists 
the MX records for a domain, and then tries to connect to each of them, 
issue an EHLO command, disconnect, then list the output of the server, 
alerting if the server supports STARTTLS. It should be easy to further 
query the server for the certificate, using some external utility called
from the script.

It requires netcat and a pair of djbdns utilities. It's a bit crude, but 
could be helpful.

Script follows:
- cut here --

#!/bin/bash
## Query the capabilities of mailservers for a domain.
##
## Requirements: nc (netcat), dnsmx and dnsip (from djbdns package)

TMP=`mktemp /tmp/queryehlo.XX`
EHLOSTRING="capquery"
TIMEOUT=15

function help()
{
cat << EOF
queryehlo - query the capabilities of mailservers for a domain
Usage: queryehlo 
EOF
exit 0
}

function checkresources()
{
ERR="";
if [ ! "`which nc 2>/dev/null`" ]; then
echo "ERROR: nc (netcat) not available in \$PATH."
echo "netcat should be part of standard distro, or can be acquired from eg."
echo "   http://www.atstake.com/research/tools/network_utilities/";.
echo
ERR="1"
fi
if [ ! "`which dnsmx 2>/dev/null`" ]; then
echo "ERROR: dnsmx (from djbdns) not available in \$PATH."
echo "djbdns can be downloaded from eg. http://cr.yp.to/djbdns.html";
echo
ERR="1"
fi
if [ "$ERR" == "1" ]; then exit; fi
}

function queryrelay()
{
if [ ! "$x" ]; then return; fi
echo "Querying mail relay $1, `dnsip $x`"
cat << EOF | nc -w $TIMEOUT $1 25 > $TMP
EHLO $EHLOSTRING
QUIT
EOF
if [ "`cat $TMP|grep STARTTLS`" ]; then
 echo "*** RELAY ADVERTISES SMTP/TLS SUPPORT"
 # insert eventual further interrogations here
fi
echo
cat $TMP
echo
echo
rm $TMP
}


checkresources
if [ "$1" == "" ];   then help; fi
if [ "$1" == "-h" ]; then help; fi
if [ "$1" == "--help" ]; then help; fi


dnsmx $1 | sort -n |
while true; do
  read x1 x; if [ "$?" == "1" ]; then break; fi
  queryrelay $x;
done

Re: Email tapping by ISPs, forwarder addresses, and crypto proxies

[Thomas Shaddack]

On Tue, 6 Jul 2004, Hal Finney wrote:

> > There are various email forwarding services, which are nothing more than a 
> > SMTP server with pairs of [EMAIL PROTECTED] -- 
> > [EMAIL PROTECTED]
> 
> Right, mostly for use as disposable email addresses.  I've used
> spamgourmet to good effect, myself.

I wrote the patch for qmail's fastforward for similar purposes. Everything 
in the name that is beyond the specified wildcard is ignored when 
resolving the mail alias (but stays there for procmail processing). As 
added benefit, the addresses that receive spam can be used for teaching 
bogofilter.

> > Messages in storage have much lower judicial protection than messages in 
> > transit. (This does not have much technical merit, in the current 
> > atmosphere of "damn the laws - there are terrorists around the corner", 
> > but can be seen as a nice little potential benefit.)
> 
> One thing I haven't understood in all the commentary is whether law
> enforcment still needs a warrant to access emails stored in this way.
> Apparently the ISP can read them without any notice or liability, but
> what about the police?

Let's expect them so as well. The ISP can hand them over to the police 
anyway, like a nosy neighbour fink finding your grass stash.

> Also, what if you run your own mail spool, so the email is never stored
> at the ISP, it just passes through the routers controlled by the ISP
> (just like it passed through a dozen other routers on the internet).
> Does this give the ISP (and all the other router owners) the right to
> read your email?  I don't think so, it seems like that would definitely
> cross over the line from "mail in storage" to "mail in transit".

If it passes through their SMTP servers, I am not sure. If it goes only 
through their routers, I'd think it's definitely in transit.

> > There can be an easy enhancement for such forwarder service; GnuPG proxy. 
> > Every email that arrives to the forwarder address, before it is forwarded 
> > to the real recipient, is piped through a GnuPG script; the recipient has 
> > then to upload his public key during the registration of the target 
> > address, otherwise the function is the same.
> 
> That's a great idea.  You'd want to be sure and encrypt the whole message
> including headers, and make the whole thing an encrypted attachment.
> Has the added side benefits of compressing the email, and you could even
> have the server do some spam filtering.

The original idea I based it on was encrypting everything including the 
headers on the sender, then decrypting it on the receiver relay, and 
adding the data about the decryption of the message into the headers in 
some unspoofable way (eg. if the headers were there already when the 
message arrived to the decrypting script, prepend X- to them - not 
really bulletproof but rather decent).

> > For added benefit, the forwarder should support SMTP/TLS (STARTTLS) 
> > extension, so the connections from security-minded owners of their own 
> > mailservers would be protected.
> 
> STARTTLS support at the proxy should pretty much go without saying these
> days, so you might as well do it, but if you're already PGP encrypting
> then it's not adding that much security.  Well, maybe it does, but you're
> talking about a different threat.

It hides the fact encrypted comm is in use. Which may be handy on its own.

> For the problem that ISPs can read your email in storage, STARTLS 
> doesn't help much because it will only protect the email until it gets 
> to your local ISP, who will store your email for you and can read it 
> then (which is where the PGP comes in).

That's true. But it protects the data in transit nearly for free.

> Where STARTTLS would help is with power users who run their own mail
> servers.  But those people don't suffer from the problem we are talking
> about here, legal access to the email by the ISP (I think, see above).
> Nevertheless a mail-receiving proxy that uses STARTTLS connections to
> power users would be kind of cool because it would keep anyone local
> from knowing anything about the incoming mail.  Hopefully, STARTTLS will
> eventually become so widespread that this functionality will be redundant,
> but we are not there yet.

STARTTLS is by far not widespread. Few people use it, including the 
knowledgeable ones. :(((

> > (I know, auto-decryption is dangerous, but we now talk about the system 
> > for one's grandma, transparent to use.)
> 
> Absolutely, look at the threat model.  You're not worried about someone
> breaking into your computer, you're worried about your ISP legally
> reading your email.  To address this threat, auto-decryption is a
> perfect solution.

It's always better to select overly restrictive threat model and then 
loose it when necessary, than the other way. An omission then results in 
more work instead of a security hole.

> He would configure his mailer to connect to localhost:4949 or whatever, 
> just like any other POP server.

With a local 

Email tapping by ISPs, forwarder addresses, and crypto proxies

[Thomas Shaddack]

Reading some news about the email wiretapping by ISPs, and getting an 
idea.

There are various email forwarding services, which are nothing more than a 
SMTP server with pairs of [EMAIL PROTECTED] -- 
[EMAIL PROTECTED]

Messages in storage have much lower judicial protection than messages in 
transit. (This does not have much technical merit, in the current 
atmosphere of "damn the laws - there are terrorists around the corner", 
but can be seen as a nice little potential benefit.)

There can be an easy enhancement for such forwarder service; GnuPG proxy. 
Every email that arrives to the forwarder address, before it is forwarded 
to the real recipient, is piped through a GnuPG script; the recipient has 
then to upload his public key during the registration of the target 
address, otherwise the function is the same. For added benefit, the 
forwarder should support SMTP/TLS (STARTTLS) extension, so the connections 
from security-minded owners of their own mailservers would be protected.

The recipient himself then can either run his own mailserver and download 
mails through fetchmail, or receive mails using SMTP/ETRN (both methods 
allow automated decryption of such wrapped mail during its receiving), or 
use a POP/IMAP decryption proxy, or have a plugin in mail client.

(I know, auto-decryption is dangerous, but we now talk about the system 
for one's grandma, transparent to use.)

The only vulnerable parts of the mail route then will be the sender's 
computer, the pathway between the sender and the forwarder server (if 
SMTP/TLS is not used correctly or at all), the forwarder server (if 
compromised), and the recipient's computer. The way between the forwarder 
and the recipient's ISP, including the recipient's mailbox, is secured.

What do you think about this scheme?

Re: Privacy laws and social engineering

[Thomas Shaddack]

On Tue, 6 Jul 2004, Major Variola (ret) wrote:

> So, which is better, Schneier's books or Mitnick's?   I suspect
> the former, but am curious what the community opinion is?

You may like one side of the coin more than the other one, but they still 
belong to the same flat, dirty, formerly shiny and now dull and mildly 
corroded disc of an alloy of not so noble metals.

Sometimes you get access by telnet. Sometimes by a voice call. Hack the 
mainframe. Hack the secretary. What's better? (Okay, I agree, you can't 
sleep with the mainframe.)

There are many ways to the hilltop. Some travelers argue what one is 
better. Others quarrel if the hilltop is more important than the pathway 
or the other way. Some don't care and march forward.

I feel zen today.

Re: China about to begin realtime censoring SMS messages

[Thomas Shaddack]

On Sat, 3 Jul 2004, Major Variola (ret) wrote:

> At 06:25 PM 7/3/04 +0200, Thomas Shaddack wrote:
> >automatically send SMS messages to a list of numbers. The government 
> >already keeps statistics on number of messages sent at time period from 
> >a single number, and alerts the officials when it's above the limit and 
> >then the content is checked manually.
> 
> What you need then is also a "telephone tree" to do mass distributions
> (randomly time-delayed) without having any one source go "over quota".

I suppose it's what Falun Gong started doing in reaction to the measure.

> Could be phone meshed or use computer SMS I/O.

If the gateways are present.

> Wouldn't it be horrible if some otherwise benign, quiet worm infected
> computers to implement this?  Zombies aren't just for porn & pills,
> they can help spread the newz.

Or act as an onion-routing anonymizing network. It's a bit drastic way of 
enforcing privacy means, but it's always better to have a nuke up one's 
sleeve in case the stakes would get way too high.

I expect it to happen in couple years. Most likely it will be born either 
in some overtly restrictive regime of Far or Middle East (including but 
not limited to China), or as a reaction to some drastic measure-to-happen 
in the Demagocratic West.

Re: Tyler's Education

[Thomas Shaddack]

On Sat, 3 Jul 2004, Major Variola (ret) wrote:

> And digital edges are sharp, in the Ghz even when the "clock" is in the
> Mhz.

How much do the "spread spectrum clock" feature on the modern motherboards 
help here?

> And boxes need ventilation slots.

Not necessarily. There are other ways of heat transfer. A good way could 
be water cooling for transport of the heat from the CPU and other parts to 
a massive metal heatsink that's the part of the case, with an optional fan 
on its outside. Voila, water cooling is not only for case mod freakz 
anymore.

> Any questions?

I expect much bigger problem in the attached cables and connectors. How to 
solve this?

China about to begin realtime censoring SMS messages

[Thomas Shaddack]

Mass-sending of SMS messages in China is a popular channel of spreading 
"alternative", government-unsanctioned news. Used eg. by the Falun Gong 
group, to spread the news about SARS, and probably in numerous other 
cases. Some phones are even directly equipped with the functions to 
automatically send SMS messages to a list of numbers. The government 
already keeps statistics on number of messages sent at time period from a 
single number, and alerts the officials when it's above the limit and then 
the content is checked manually. Mentioned Falun Gong news campaigns 
suffer from this.

The new system, delayed by technological problems probably caused by the 
sheer volume of data, will scan the messages for keywords, keep logs of 
suspect ones, and automatically alert police.


According to me, a partial solution of the problem could be deployment of 
encrypted messaging. The SMS standard, 160-character messages, doesn't 
offer enough space to fully use PKI (though we could sacrifice some 
message space - then we could afford 128 bits of key and 128 bits of HMAC, 
which is total of 32 characters, or maybe even use reduced HMAC of only 
half size as in this threat model we don't need the message integrity as 
much as denying the adversary access to the content, 64 bit hash could be 
enough). We can sacrifice also signing the message, or give the choice of 
signature vs additional content length (the signature is the message hash 
encrypted with the sender's private key, which is about another 128 bits; 
we could perhaps use only 64-bit of signature in this threat model). We 
can sacrifice the identification of sender/receiver keys (or more 
accurately, we can't even afford it in so short message space), but the 
GSM SMS standard has the sender phone number as part of the message, which 
can serve as identificator of the sender's key for eventual message 
signature check.

Contemporary cellphones tend to have Java in them, and should have enough 
horsepower for 1024-bit RSA and 128-bit AES. 

However, according to my consultant, there is a problem with most of the 
cellphones; Java on them runs in sandbox, so they can only send the 
messages (and even that only when they have access to messaging API), and 
there is no access to message inbox. So you can merrily encrypt, but the 
receiver then won't decrypt it. There is a solution, though - use a phone 
with OpenAPI, eg. running Symbian, Linux, or (*shudder*) WinCE as its OS, 
but these are so far in the higher end of price spectrum. I hoped it will 
be possible to implement with already widely deployed cheap technology. :(

Another hope lies in the advent of MMS, expensive now but bound to become 
a standard bulk commodity service tomorrow, which offer much bigger space 
(up to 64 or even 100 kbyte per message). Same problem as above applies.

Then all the adversary can get is the pattern of traffic of the messages 
instead of their content. (And the message content too, but only when 
seizing the recipient's private key - I am not sure if we can avoid this 
in this scenario, without resorting to using one-time pads and using them 
correctly, or without using a direct handset-to-handeset connection, 
perhaps through a proxy, with a DH key exchange. The proxy could be very 
beneficial here, even for the traffic analysis purposes, if combined with 
onion routing.)


-
Yahoo News:
http://news.yahoo.com/news?tmpl=story&cid=516&u=/ap/20040702/ap_on_re_as/china_mobile_phone_surveillance_3&printer=1

BBC News:
http://news.bbc.co.uk/1/hi/world/asia-pacific/3859403.stm

The Register:
http://www.theregister.co.uk/2004/07/02/china_text_snoop/

Slashdot discussion:
http://slashdot.org/article.pl?sid=04/07/03/0035224

Unregistered

[Thomas Shaddack]

Found this on the Net couple years ago. Then it vanished. In the light of 
the INDUCE Act, or whatever it's called now, it is becoming quite 
relevant...

Question for the crowd: In the setting described below, how could one 
perform a successful long-term disobedience?


Original URL: www.keshet.f2s.com/unregistered.html
Downloaded Sep 1 2001

Unregistered


Dark and drizzle, we pulled up in front of the living block; we had a an 
AC tip on one of the residents -- nothing concrete, maybe trafficking in 
illegal copies, maybe just pron, we weren't sure.

"Can I help you?" our suspect asked, innocently enough, as he opened the 
door.

"Yah, we got a warrant - need to scan your disk." I held up the warrant in 
one hand while the other reflexively went for the scanner.

"What seems to be the problem officers?" he says... boy if this guy is 
hiding something he sure can act it. This is the point when I watch the 
suspect most closely -- looking not just for fear or guilt, but any kind 
of movement which may trigger an erase mechanism.

"Nothing special," I try to smooth him over, "just a routine search, maybe 
we just got a bad tip."

"Well, okay.." he didn't seem too sure of his ground. I didn't like it, he 
should be outraged, or afraid or something. My partner printed up a 
receipt while I activated the scanner.

3 seconds later I'm looking at the output, scratching my head- no 
  contraband on the disk but the scanner flagged some unusual files.

"What's this?" I ask the guy, showing him the readout.

"Oh, those are mine," he said with such an innocent look I was caught off 
balance.

I connect to Central and send the digital signatures for look-up & 
verify.. Central drew a blank. "Unknown registry authority" was the 
response for each one of the signed executables.

"Where did you get these?" I ask the suspect while copying the binaries 
into quarantined flash for later dissection.

"Those? I made them." Again that look of pure innocence. I was getting a 
creepy feeling at the back of my neck.

"Whadd'ya mean, you made them? Look, we're gonna find out where those 
execs came from and what they do.. it's gonna start getting real 
unpleasant in here real fast if you don't start coming up with answers 
quick!" I don't like coming down heavy so fast on a guy, but these files 
were starting to give me the creeps.

"Look man, I'm a programmer - that's what I do. I can show you the source 
& compile it for you if you like..."

Stunned, I look at the guy, my partner's already going for a tackle with 
the cuffs. "You got a compiler in here!?" I shout at him. "Jesus HC," I'm 
swearing at myself for being so slow.

"Call Central!" I'm yelling at my partner while I signal for backup, "tell 
'em to put a packet freeze on the whole damn block! Tell 'em we got an 
unregistered compiler!"

I swear to God, even while they were hauling him away & forensics were 
scanning the building, he still had that innocent look on his face -- like 
he didn't even know what was going on.


All Text and Art Original Material Copyright © 2001
mailto:[EMAIL PROTECTED]">keshet

Re: Silicon carbide in the machine

[Thomas Shaddack]

On Mon, 28 Jun 2004, Major Variola (ret) wrote:

> >A GPS receiver doesn't broadcast its location. GPS works purely by 
> >analyzing the signals received from satellites. This is probably a 
> >design goal for military use, as well as a consequence of power 
> >requirements.
> 
> Yes.  But a jammer will draw a Hellfire.

A $50 jammer for a $500,000 missile. Sounds like a fair trade to me. ;)


> >It seems that for CDMA or WCDMA phones the location service is defined 
> >in terms of messages on the normal network layer, see a Google search 
> >for "position determination service order".
> 
> Yes its cheaper and allowed (for now) to triangulate (to what, 100m?)
> using physics; but GPS will become cheaper and cheaper.

Which is good, because once the adversary starts relying exclusively on 
GPS and lets the other monitoring systems decay, we have easier way to 
"deny that service" from our handhelds. Physics is more difficult to cheat 
than chips.

Re: For Liars and Loafers, Cellphones Offer an Alibi

[Thomas Shaddack]

On Sun, 27 Jun 2004, J.A. Terranson wrote:

> > > Even if this is doable, it is out of reach of Jane Citizen.
> >
> > If a J. Random Hacker with the necessary capabilities is within her reach,
> > the countermeasure is available to her regardless of her own tech skills.
> 
> You assume that Jane's only problem is equipment procurement.  Alas,
> Jane's biggest problem has not changed much in the last 100 years:
> knowledge.  Jane doesn't know this is an issue that she might need help
> with.

We have a large unwitting helpmate: the Media. Their primary motivation is 
the eyeballs, the Nielsen ratings; which can be exploited for Spreading 
The Word. Technology, while difficult to understand for mere mortals, 
together with its handlers, has its appeal - not entirely dissimilar to 
witchcraft of the Medieval Times; see the popularity of the topic of 
computer security breaches between journalists.

They will get it wrong. But Jane can be corrected; the important task for 
the Media is to make her aware about the possibility and get her to ask. 
At that stage, the incorrectness in the media reporting can be corrected.

If Jane becomes aware about at least a subset of the possibilities, the 
Media did their job.

> > With continuing outsourcing, there should be enough out of work engineers
> > available who are sufficiently hungry to risk working for the underground
> > market.
> 
> I've wondered over the last several years why such a market has not been
> more openly extant.  This thought has occurred to me many times since the
> last 70's - the stuff you want is available, but barely, even if "legal".

It's not as wide as it should be. However, it's far from nonexistant; 
there are eg. alternative firmwares for DVD drives, with stripped zoning, 
firmwares for cellphones with removed operator lock, and many other 
goodies.

I suppose the fundamental problem here is the lack of skilled-enough 
people, combined with closed technology; it's rather difficult to 
disassemble a program from binary, takes a lot of time and in many cases 
is impractical. Another problem is the technology the electronics is being 
manufactured now: everybody can work with 2.54mm DIL chips, not everybody 
can work with 0.125mm SMD chips, and only a selected few have access to 
technology necessary for BGA chips. :(

This could be partially offset by some hypothetical new generation of 
visual disassemblers, showing code not as an endless stream of 
instructions but as a graphical representation of the execution flow, 
perhaps using some tricks from atomic-level visualisation of huge and 
complex biochemical structures, eg. proteins and intracellular structures.

Another hope, closer and more realistic one, is in the emergence of 
smaller manufacturers, voluntarily opening their devices in the hope for 
market advantage (the Linksys box mentioned here may be a good example).

The remaining problem is the hardware level. Hopefully somebody with 
enough skills and a good idea appears (or perhaps already appeared) and 
designs a way how to make work with the tiny chips easier for a garage 
workshop; there are trends along this direction already, I saw a mention 
of a reflow oven for SMD boards, made of a toaster.


Never lose hope, and never stop doing things. If you can't solder, code. 
If you can't code cryptosystems, code tools. If you can't code at all, 
write articles and spread awareness. If you can't even write, talk with 
friends. If you don't have any suitable friends, at least read and learn 
yourself. Even an otherwise meaningless act may mean a lot if it comes at 
the "wrong" place and the "wrong" time.

See the "Patriot Ants" approach I mentioned couple weeks ago in the 
Zombie Patriots thread.

Re: For Liars and Loafers, Cellphones Offer an Alibi

[Thomas Shaddack]

On Sun, 27 Jun 2004, Riad S. Wahby wrote:

> "J.A. Terranson" <[EMAIL PROTECTED]> wrote:
> > Interestingly, some [early] models had external antenna jacks built in to
> > them.
>
> Many still have test jacks on them.  Both my old Samsung A500 and my
> current Sanyo SCP-8100 have a connector (either MC or SMA, IIRC) on the
> back hidden under a rubber plug.  My guess is that with an appropriate
> connector you could use, e.g., a pringles can to make your antenna much
> more directional.

Many phones have such connectors used by car handsfree holders, in order
to use an antenna mounted externally on the vehicle instead of
transmitting from the handset into the partially open Faraday cage of the
car.

RF-skilled people should have no problems adding such connectors to their
phones even if they aren't there from the factory.

Re: For Liars and Loafers, Cellphones Offer an Alibi

[Thomas Shaddack]

> At 12:41 AM 6/27/04 -0500, J.A. Terranson wrote:
> >On Sat, 26 Jun 2004, Major Variola (ret) wrote:
> >
> >> At 11:56 PM 6/26/04 -0500, J.A. Terranson wrote:
> >> >
> >> >Hrmmm... Cell Phone.  TEMPEST Case.
> >> >
> >> >What's wrong with this picture???
> >>
> >> 1. You can't receive calls.  Only make outgoing, from a location
> >> which is known to fascists.
> >
> >Let's try again.  TEMPEST sheilding and outgoing calls are not
> >compatible.
>
> Of course outgoing is impossible inside the TEMPEST box.
> But you don't reveal the intermediate locations you drove
> through to get to where you broadcast.

For this purpose, plain power-off should be enough.

The "RF fingerprinting" I mentioned earlier is a different grade of threat
though; against that, shielding is necessary.

> >> 2. Use it for your toll-road-transponder too.
> >
> >And you own one, why?
>
> I don't, because I'm a cheapo and professional paranoid.  But in my
> 'hood, there are many tollroad which use them.  Otherwise you have
> to stop and toss coins.  Of course your license and face are video'd
> anyway.
>
> If I had one, I would box it unless I was driving on a toll road.

There are two kinds of tags, active and passive. Active ones have their
own power supply on board and transmit on their own, passive ones need
external field to feed them with power.

A good thing could be a detector of the passive tag readers; similar to
car radar detectors, just on different frequencies.

A detector of active tag readers should be possible to design as well;
the receivers are usually designed on the superheterodyne principle, and
the leaks of their oscillators can be detected from distance. In some
countries/states police uses detectors of radar detectors working on this
principle, and there is also some project of advertisement corps to
receive the leaks from the car radios and figure out the major demography
of the population using a given road and set the "most suitable" face of
the billboards on that road for that particular target group. So the
technology is already out there, just has to be opensourced for public
benefit.

Shame on my lack of RF skills necessary to do this :(((

Re: For Liars and Loafers, Cellphones Offer an Alibi

[Thomas Shaddack]

On Sun, 27 Jun 2004, Eugen Leitl wrote:

> Triangulation by signal strength is one thing, triangulation by relativistic
> ToF (time of flight) -- while still not present in consumer gadgets -- is far
> more difficult to fool. Especially if it's tied into the protocol, that
> you're getting position fixes along with your sent packets.

You may cheat and use the geography, if suitable, to your advantage. Use a
high-gain antenna and bounce the signal off a suitable cliff or building.

Multipaths don't have to be enemies; pick a suitable one and use it as a
cover. The added advantage is fooling both the direction and the distance.

Re: For Liars and Loafers, Cellphones Offer an Alibi

[Thomas Shaddack]

On Sat, 26 Jun 2004, Major Variola (ret) wrote:

> I'm fully aware the pigs track you unless the battery is removed or you
> have a TEMPEST case.  I'm suggesting that regular citizens will have
> access to that, if (in my cluelessness) they don't already.

If the phone is shielded, it can't transmit/receive, which makes it rather
useless. :(

There is one potential landmine as well; the inherent ability of any
device containing resonators to behave like a crude RFID tag. I heard
somewhere, and my memory may be failing, that it is possible to irradiate
the phone with the frequency of the cellular band, and it faintly
resonates and returns back its own echo, which has minute variations given
by type, manufacturing tolerances, and possibly age of the phone, giving
it a kind of unique signature. (This could potentially apply also to
radios and transceivers. Does anybody have any idea if it is possible to
do such kind of "active fingerprinting" of rf devices? This way it should
be possible to detect even powered-off devices like hidden transceivers or
body wires; take a transmitter, sweep the spectrum, and watch echoes on
the receiver - there could be peaks on the frequencies of the tuned
circuits inside the examined device.)

Question to RF heads here: could it work?

Re: For Liars and Loafers, Cellphones Offer an Alibi

[Thomas Shaddack]

On Sat, 26 Jun 2004, J.A. Terranson wrote:

> > Eventually the cellphones will be able to tell another phone approx
> > where they are.  Remember the 911-locator fascism?
>
> I hate to break the news to you Major, but GPS enabled phones cannot be
> instructed to turn off the GPS feature for law enforcement queries (e.g.,
> 911).  Turn it on or turn it off, makes no matter.

Can it be disabled by hardware hack of the phone, a mikropower jammer, or
using an "unofficial" firmware?

Re: For Liars and Loafers, Cellphones Offer an Alibi

[Thomas Shaddack]

On Sat, 26 Jun 2004, J.A. Terranson wrote:

> > a mikropower jammer,
>
> Only if you are willing to forego the phone as well, in which case, just
> remove the battery pack :-)

I am assuming here that the phone has a dual receiver, one of the GPS
signal and one of the cellular service itself. As both operate on
different frequencies, it should be possible to jam one while keep the
other's service intact. As we can feed the jamming signal right into the
antenna of the receiver which we can physically access, we can use very
very small powers, which lowers the chance of the jammer to interfere with
other devices we perhaps would like to keep in operation, and makes us
less susceptible to be annoyed by the FCC goons.

Re: Low-elevation skymapping at 2.45 Ghz

[Thomas Shaddack]

> The best way to do this is to mount the narrow-angle dish *and* video camera on
> the same mount, then use simple circuitry to superimpose white circle on the
> center of the image when signal exceeds some threshold (or vary the size with
> signal level.) The results could be startling.

You could also use a stepper motor connected to the polar mount, and scan
the sky (or the city under the hill) automagically.

This could be interesting even in other bands. Could create some pretty
pictures. :)


Could it be possible to achieve the same without using a movable antenna?
Eg, by an antenna array and comparing phases of the arriving signals?

Re: [osint] Assassination Plans Found On Internet

[Thomas Shaddack]

On Mon, 14 Jun 2004, R. A. Hettinga wrote:

> I can't stop laughing. *This* is why the west will win.
> They post their plans, in the clear.

It may be also a very cheap method of "attack". Don't spend any money on
material nor people; just send out an attack documentation in the clear
and watch the adversary jumping around, wasting their resources, and
getting their morale worn out a little bit more with every further false
alarm.

RE: [irtheory] War ain't beanbag. Irony is conserved.

[Thomas Shaddack]

> >Exactly at which point does a war (any war) stop being defensive
> >because according to the history books the US has never fought an
> >aggressive war.
>
> I prefer to think about the McDonald's paradox: No country that has a
> McDonald's has attacked another. :-).

Then either the paradox is dead wrong, or there is something unclear on
the definition of what counts as "attack", as Clinton would say.

> Life is hard. Sometimes, people with guns come and kick your ass. If
> you don't have guns, you can't kick their ass.

You can, but you have to have MUCH more superior strategy, and lots of
luck.

Weapons can mean a lot, but they are far from being everything.

Re: Satellite eavesdropping of 802.11b traffic

[Thomas Shaddack]

On Thu, 27 May 2004, Roy M. Silvernail wrote:

> >It seems to me that you'd need a pretty big dish in orbit to get that kind
> >of resolution.
> >
> >The Keyholes(?) are for microwaves, right?
> >
> Where better to put the big dish than in orbit?  Clarke-belt birds are
> separated by what, 10 km?  So a 5 km dish would be feasible.

No big dish should be needed for resolution. Radio astronomy is done by
arrays of smaller antennas. Precise measurement of relative position of
the satellites can be done about as well as with the antennas on the
ground. Smaller dishes in known distance should work as well. We should
also keep in mind that the high-sensitive receivers are cooled so they are
rather low-noise.

Re: welcoming computer viruses

[Thomas Shaddack]

On Fri, 21 May 2004, Tyler Durden wrote:

> Imagine I'm working for a large Fortune 100 Company. Now imagine I hear
> about a sasser-like worm that will install atself and spread, BUT "it has
> been confirmed" that the worm will proceed to vomit spam at X for a period
> of 48 hours. Depend on X (eg, the CIA, Microsoft, Re-elect George W...) I
> might be more than willing to download that virus, provided I had some kind
> of assurance that it wouldn't trash all my work (and if it closes down my
> company for a day or two, all the better 'cause I'm way overworked).
>
> Of course, I'll need plausible denial: "Oh, I thought that was my boss
> sending me a file...").

If it is a .vbs mail worm, or something similar that spreads as an
interpreted script, you can get your assurance about the worm's function
by examining its source code.

But every coin has two sides (and the so-often neglected edge) - it also
makes it easier to quickly create evil data-damaging versions of the worm.

RE: EU seeks quantum cryptography response to Echelon

[Thomas Shaddack]

On Tue, 18 May 2004, Tyler Durden wrote:

> "Monyk believes there will be a global market of several million users once
> a workable solution has been developed. A political decision will have to
> be taken as to who those users will be in order to prevent terrorists and
> criminals from taking advantage of the completely secure communication
> network, he said."

Hope the technology hits the streets fast enough after getting on the
market. Monyk apparently doesn't believe that people who don't have the
money to buy the Official Approval have no right to access to this
technology.

> Silliness itself, at this point. Practical quantum cryptography at this
> point is limited to transmission. The moment it goes O/E, it's as vulnerable
> as any other data. And terrorists aren't going to bother splicing fiber.

There are quite many important activities that don't require storage of
the transported data.

For example, very very few people record their phone calls.

Diffie-Hellman question

[Thomas Shaddack]

I have a standard implementation of OpenSSL, with Diffie-Hellman prime in
the SSL certificate. The DH cipher suite is enabled.

Is it safe to keep one prime there forever, or should I rather
periodically regenerate it? Why? If yes, what's some sane period to do so:
day, week, month?

If the adversary has a log of a passively intercepted DHE-RSA-AES256-SHA
secured SSL communication, presuming the ephemeral key was correctly
generated and disposed of after the transaction, will the eventual
physical retrieval of the DH prime (and the rest of the certificate) allow
him to decode the captured log?

I am rather inexperienced in this area, don't want to make a mistake, and
generation of 2048-bit primes is CPU-hungry enough to not decide to just
throw it in without a good reason.

Re: We're jamming, we're jamming, we hope you like jammin too

[Thomas Shaddack]

> RFID jamming should be very easy and a quite amusing DoS attack
> on commercial targets.  Easy because its not frequency hopping, low
> power, and relatively low frequency.  Particularly cute would be
> transmitting sex-toy codes intermittently.

Considering the transmitting powers of the tags, an active battery-powered
transmitter with a suitable antenna could have rather long range. A small
circuit with a battery could be magnetically attached to a car of a
selected "victim" and switched on after a delay, resulting in a mobile
jamming platform. Parking lots in front of the stores, where there is
often a direct line of sight between the cash registers and the cars, are
especially suitable for this kind of attack.

> ASK any Elmer you happen to see,
> what's the best jamming, RFID..
> (With apologies to the tuna industry and those too young to
> know the jingle.  Or to know the RF double meanings.)

Interesting cultural reference that goes entirely above my head with a
cute swooshing sound.
Care to explain, please? :)



For personal defense, I came up with a similar, smaller-range and
lower-power idea:

-
Micropower RFID jammer
Very-low power passive/active jammer of passive RFID tags

Radiofrequency tags bring a wide variety of privacy-related concerns. A
semi-passive jammer may be an option to alleviate some of them.

The tags are powered from the electromagnetic field the reader irradiates
them with, then they transmit back on another frequency. The transmission
takes some time, I guess few milliseconds, and is detectable by a nearby
receiver.

The tags are made in two kinds: "plain", and more advanced
collision-resistant ones. The first kind transmits blindly whenever
powered, repeating its signature over and over, which causes two tags
within the field of one reader to jam each other, as their responses get
mixed together. The second, more expensive kind, uses algorithms to avoid
the situation when two tags transmit at the same time, overlapping their
responses and making them difficult to recognize; most often detecting
another tag transmitting, and then going silent for random amount of time.

This behavior makes it possible to design a micropower jammer. The device
shall listen on the frequencies both the readers and the tags transmit on.
When the tag read attempt is detected, the device owner may be alerted -
by a LED, a sound, a vibration. Then when the device detects the tag's
attempt to answer, it broadcasts pulses looking like the answer of another
tag, forcing a collision and a misread into every answer. The tiny power
required for occassional transmitting of few very short pulses makes the
device unlikely to cause other kinds of trouble, while additionaly making
it less easy to be detected if declared illegal than "continuous" jammers.

Re: Can Skype be wiretapped by the authorities? (fwd from em@em.no-ip.com)

[Thomas Shaddack]

On Sun, 9 May 2004, Eugen Leitl wrote:

> Not only that: NATted agents cannot be "called" unless they first register
> with some reflector on the open Internet. And centralized reflectors are,
> again, easy to attack, and also expensive to operate, as the bandwidth
> requirements are substantial (all the traffic flows through them): see
> e.g. John Walker's analysis of the reasons that led him to abandon
> SpeakFreely at http://www.fourmilab.ch/speakfree/ .
>
> Thomas Shaddack suggested to leverage on Jabber, but:
>
> 1. Jabber uses TCP as transport, and therefore can't be efficiently used
> as transport for telephony, i.e. using encapsulation of the voice packets
> in the Jabber protocol in order to traverse NAT devices.

Oh! There is a little misunderstanding here!

I proposed using Jabber for the presence/location/directory thing, and for
negotiation between the clients about what method to use, if they can do
direct peer-to-peer call or have to use a reflector (and what one), what
cipher and key to use, etc. - the Jabber protocol is rather unsuitable for
VoIP.

> 2. Jabber is based on a client-server paradigm similar to e-mail. Running
> a Jabber server requires an always-on machine with its own domain name;
> and, although dynamic DNS can help, the model again tend to be
> hierarchical, easy to attack etc. That pretty much rules it out also for
> session initiation, directory/presence etc.

That's true - but it can be implemented with relative ease, with lots of
infrastructure already existing. Next generation of the system then can
be built atop this.

> The beauty of Skype, encryption aside, is that it's based on an overlay
> network solely based on P2P servents, relies (if their FAQ tells the
> truth) upon NO central registry for presence and directory services, and
> each client that runs non-NATted can transparently act as reflector
> supporting NATted users. Plus, all this (including, besides voice,
> text-based instant messaging) works with zero configuration with an
> idiotproof UI.

But it's closed-source and so can't be fully trusted :(

Re: Fact checking

[Thomas Shaddack]

On Wed, 28 Apr 2004, Tim Benham wrote:

> > I bet people would start voting after that.
> If they don't, offer them two vials of crack!

It's already being done; it's called "political promises". The candidates
are usually pretty high on that stuff.

What won't hurt could be making them liable for their promises, as they
can be considered to be a contract with the voters. With specific
penalties for not delivering the results in the specified timeframe.

Infrared flash?

[Thomas Shaddack]

For bright flashes of visible light, xenon flash tubes are the choice.

But when I want a really bright flash on about 800-900 nm, what approach
is the best?

One application is a security camera taking a snapshot without alerting
the adversary with a flash. (Could be a good system against black-bag
jobs.) Another application, with higher flash frequency, could be a
stroboscope throwing the AGC circuits in cameras off-track,
Macrovision-style.

What would be the best approach? The energies here are more in the range
of rotation/vibration changes than electrons jumping up and down between
the energy states. How to convert a blast of electrical energy into a
shower of near-IR photons?

Re: Mask secures personal displays

[Thomas Shaddack]

>  Yamamoto is also optimistic that this technique will find commercial
> applications. "Display of secret information on PDA and computer screens
> are practical applications," he explained. "Other business applications
> include: securing the screen of a terminal at a bank; an operator screen
> that shows personal information; and a touch panel screen of a safe."

Question: if there is a goggle version, why not use a "real" wearable
display instead, eg, the kind by www.microopticalcorp.com ?

Re: cop-proof disk drives

[Thomas Shaddack]

On Sat, 24 Apr 2004, Bill Stewart wrote:

> That's really overkill.  Computers these days have enough
> horsepower to run file system encryption in the CPU.

That's true, but it's possible to get access to the key in memory. Once
the machine is compromised, the keys are leaked.

It's true that when the machine is compromised the plaintext data may be
leaked, but it's more difficult to inspect and transfer couple gigs of
data than just the key and then come and haul away the machine. Or to
compromise the encryption software itself. It's much more difficult to do
that with a hardware unit (and much more difficult if the case was eg.
spot-welded - you still can get inside using power tools, but not without
visibly damaging the case).

Another advantage of a pure-hardware solution is independence on software,
thus no risk of present nor future incompatiBILLities.

> If you want to get fancy about rubber-hose prevention
> and avoid the except-for-terrorism clause in the 5th amendment,
> you could do something with secret-sharing with your
> unindicted co-conspirators (oh, wait, they don't bother with
> indictments these days, do they?) so that all of you
> need to cooperate in a challenge-response thing
> to restart some of the services.

I'd suggest a m-of-n scheme because of reliability issues. It won't be
good to lose all data because one of the co-conspirators died in a car
crash.

> Or you could hide that little 802.11 widget on the shelf
> that stores one of the keyfiles you need to
> access the secure drive.  Once UWB's widely available,
> it'll be better for that (lower power - harder to detect.)

A 802.11 standalone data storage unit (I think they're on sale already)
hidden under the floor, over the ceiling, or between the drywalls could do
the job nicely.

> Just make sure that your system _is_ restartable after
> power failures, because those are a much more likely event
> than cop invasions.

Reliability vs security is a big dilemma.

Maybe a good approach could be forgetting the key if the machine is moved
without telling the processor guarding the key that it should stop
watching a movement sensor for a given time interval, or after entering a
wrong (or kill-) PIN? A power blackout then won't affect the operation,
but switching the equipment off and hauling it away would destroy the
keys. Same as an attempt to bruteforce the access code, or opening the
machine case by force.

Re: [IP] One Internet provider's view of FBI's CALEA wiretap push

[Thomas Shaddack]

On Fri, 23 Apr 2004, A.Melon wrote:

> Are there any publicly available documents that detail interrogation
> protocols and what brainwave patterns and bloodflow look like during truth
> telling and lying?  Preferably something that gets into how to consciously
> alter brainwave patterns and bloodflow with this application in mind...

There is other possibility how to "beat" interrogation - suitable only for
some subsets of situations, when the organization design is prepared for
this.

Tell them all. Tell them the truth. Make sure in advance that you can
afford to do it without telling them what they need/want to know - design
the system the way you won't be *able* to know the information that could
endanger the "important" parts of your system/organization.

Re: [IP] One Internet provider's view of FBI's CALEA wiretap push

[Thomas Shaddack]

On Fri, 23 Apr 2004, Major Variola (ret) wrote:

> >> filesystems (etc) with layers of deniable stego.
> >Are there any decent implementations for Linux/BSD/NT?
>
> I haven't looked recently.  One property that such a FS or app should
> have is that it is useful for something *else* besides stego & duress
> layers. Maybe a watermark :-) management tool that can embed multiple
> watermarks that don't interfere.  Hmm... a meaty problem... tasty, with
> heavy theory sauce..

Regarding filesystems, some time ago I came up with an idea of a
filesystem as a block device that has the filesystem handling code in its
bootblock area in a bytecode. Mount the fs, it reads the functions into
the interpreter's sandbox. Could be useful especially for read-only media
that would be using exotic encryption or compression algorithms, and
quick portability of them between various OSes; you have to develop only
the interpreter and the filesystem API for any OS in question, the rest
is on the medium itself.

I recently stumbled over an extremely interesting Linux project, "FUSE" -
filesystem in userspace. The fuse.o module serves as an interface between
the kernel and user space, relaying the filesystem-related calls. It's
quite robust approach, as any crash of the external filesystem code is in
userspace and is unlikely to take down the machine itself. Wondering if
something like that could be written for Windows. Would simplify a lot of
things.

> >There are magnesium rods on the camping market, sold as firestarters for
> >very bad weather.
>
> One can also buy mag ribbon which is more convenient than the
> mini-ingots you are referring to.  I know that pyrotechs coat Mg curls
> and the like with blackpowder paste (apply wet then dry).  A coil of
> coated ribbon and a rocket-igniter would make a neat little
> daughterboard :-)  Just don't take it on an airplane. There are patents
> on similar, of course.

Somebody mentioned here the trick with KMnO4 and glycerol. I saw this
experiment in elementary school, where it was shown as a demonstration
that mixing "ordinary" things may give extraordinary results - it was
shown to light up a glob of magnesium shavings. A setup with a dongle
circuitboard covered with an insulating/protective varnish, a magnesium
strip attached over the memory chip (held in place by steel wire thick
enough to keep it there even while burning, for long enough to deliver
enough heat into the chip, or wrapped around the chip and the board), the
strip coated with caked permanganate, and a glass vial with glycerol in
the dongle's casing, could be usable for the field use - if you get enough
time to drop the dongle and step on it. Electrical ignition of the Mg
strip may be useful in the setups when the device is connected to home
security system or machine movement sensors.

A purely electronic system would have an advantage, though - could be
shipped much easier as it won't contain more "dangerous" components than a
lithium or silver-oxide cell. Maybe a microcontroller with a SRAM chip,
with the data stored as XORs of pairs of cells, and the micro periodically
inverting the pairs, to prevent the "remembering" in the SRAM cells after
a power-off? (Related question: are there any SRAM chips with smaller
capacity, that would have smaller case and smaller number of pins?)

> Testing might get expensive unless you can get destructive-test dongles
> cheaply, and how much effort do you expend trying to read the data?

Or replace the test dongles with test rig with a mechanically similar
chip; new serial EEPROMs in SMD casings can be bought for as cheap as
USD1/3-1/4, maybe even less. We don't need to completely obliterate the
chip; we need to heat it just enough to get the electrons from the
floating gates (maybe my terminology is wrong, but if you saw a pic of an
EEPROM or FEPROM cell, you are likely to know what I mean), get them over
the not-that-high energetical barrier so they can (and will) jump back and
forth freely, discharge the memory cells. Then not even the most expensive
atomic-level machinery can recover the original content. If the
temperature is enough to recrystallize the silicon at the chip surface, it
should have a rather wide safety margin. The casings of the SMD chips are
fairly thin - under a millimeter between the surface and the chip, so even
a relatively small strip should be enough. Tests can be done even with
discarded chips, as the remains aren't required (nor supposed) to be
functional anyway - they have to be examined by eg. optical microscopy.
Electron microscopy would be the best - but that's outside of the reach of
a "garage technician"; maybe an university or an industrial lab could be
hired or bribed to do the tests, though.

Re: [IP] One Internet provider's view of FBI's CALEA wiretap push

[Thomas Shaddack]

On Fri, 23 Apr 2004, John Kelsey wrote:

> The obvious problem with multiple levels of passwords and data is: When
> does the guy with the rubber hose stop beating passwords out of you?
> After he gets one?  Yeah, that's plausible, if he's convinced there's
> only one.  But once he's seen a second hidden level, why will he ever
> believe there's not a third, fourth, etc.?  The same calculation
> applies to a judge or district attorney.  He *knows* (even if he's
> wrong) that there's evidence of kiddie-porn, drug dealing, etc., in
> there somewhere.  He knows you've given up two passwords.  Why is he
> ever going to let you out of jail, or ever going to reduce the charges
> down to something a normal human might live long enough to serve out
> the time for?

This serves a purpose as well.

Why would you ever cooperate if you can't expect much from the deal
anyway?

RE: [IP] One Internet provider's view of FBI's CALEA wiretap push

[Thomas Shaddack]

> Right, there are at least two workable solutions-
>
> Hard drives with user alterable firmware. I surprised that none of the
> major drive manufacturers seems to have thought about offering a version of
> their controllers, for substantially more money, that offers this.
>
> A retrofit device that screws into the side of the hard drive and is set to
> inject a corrosive that almost instantly destroys the drive surfaces.  The
> device can be triggered by any number of intrusion detectors or a
> voice-activated system keyed to the operators voice print.

Maybe there is also a third solution: a FPGA sitting on the IDE bus
between the disk and the controller (optionally as a PCI controller card),
realtime-encrypting the data with something suitably strong, eg. AES256,
with the key stored in a way that's easy to destroy it - most likely a
self-contained tamper-resistant device that forgets the key under a range
of conditions: if a wrong access code gets entered n times, if a door
sensor detects forced entry, if a kill-switch is pressed, if a machine is
moved without the correct movement-authorizing code is entered before,
anything that fits the threat model. The key itself can be destroyed
pyrotechically (burn, chip, burn), or just let a RAM forget it (where the
RAM may be a battery-backed microcontroller system which shuffles the bits
through a SRAM periodically in order to avoid problems with retention
after power-off; the algorithm then can be chosen in the way that makes it
more difficult to eavesdrop on the electromagnetical emissions and power
consumption variations - a lot of this problematics is already solved by
the secure-smartcards industry).

Optionally, backup of the code is possible in many forms, if the desired
safety/reliability requires recovery from accidental key erase. The key,
being just 256 bits, may be stored in myriads ways, including a m-of-n
scheme where the parts are stored in various places or under control of
different people. Serial EEPROM chips could be suitable as containers, as
they are easy to work with, small, easy to transport and hide; this
requires a degree of security-by-obscurity, but the possibility to require
m chips (or other containers) (which could be under control of other
people, including offshore entities) could alleviate this to certain
degree.

Re: [IP] One Internet provider's view of FBI's CALEA wiretap push

[Thomas Shaddack]

On Thu, 22 Apr 2004, Major Variola (ret) wrote:

> >However, it's not entirely reliable. At some point, the suspect tells
> >you what you want to hear, whether or not it is the truth, just so you
> >leave him alone. It can even happen that the suspect convinces himself
> >that what he really did what he was supposed to do.
>
> Interrogators check out each confession.  First ones won't work, bogus
> keys.  Just noise.  Second confession reveals pork recipes hidden in
> landscape pictures.  Beneath that layer of filesystem is stego'd some
> porn.  Beneath that, homosexual porn.  But your interrogators want the
> address book stego'd beneath that.  They know that these are stego
> distraction levels, uninteresting to them.  You'll give it to them
> eventually.

Or not - if you weren't who they thought and there really was nothing more
than the gay porn.

> If you give them a believable but fake one, it will damage
> innocents or true members of your association.

Innocents could be a good "cannon fodder" that can bring a lot of
backslash and alienation aganst the goons, stripping them from public
support.

> >This brings another ofren underestimated problem into the area of
> >cryptosystem design, the "rubberhose resistance".
>
> My comments were written with that in mind.  I'm familiar with
> filesystems (etc) with layers of deniable stego.

You are one of the few who are familiar with it.

Are there any decent implementations for Linux/BSD/NT? Some time ago I was
looking around for something (not necessarily stego, "standard"
single-layer encrypted filesystem would be enough) for removable media,
and would like to share them between machines running several operation
systems. Didn't manage to find anything usable. The requirements are
security, stability, and portability (at least read-only) between
platforms.

> I wonder how quickly one could incinerate a memory card in the field
> with high success rate?   Destroy the data and the passphrases don't
> help.

There are magnesium rods on the camping market, sold as firestarters for
very bad weather. Very high temperature of burning, with proper mechanical
configuration (card strapped between two such rods?) could be enough to
melt the chip.

Maybe could be used together with some kind of break-and-shake chemical
ignition even for eg. the USB drives. Their casings typically have
considerable amount of space (few mm, enough for a Mg strip) over the chip
that carries the data themselves.


Which reminds me there are toilets designed for burning the waste using
propane burners or electrical heating elements. Could be possible to use
them as a basis for the "ultimate document shredder", if combined together
with a standard lower-security one, within $2000 total.

Re: [IP] One Internet provider's view of FBI's CALEA wiretap push

[Thomas Shaddack]

On Thu, 22 Apr 2004, Major Variola (ret) wrote:

> At 12:09 PM 4/22/04 +0200, Eugen Leitl wrote:
> >
> >Are you truly expecting a worldwide ban on encryption? How do you prove
> >somebody is using encryption on a steganographic channel?
>
> Torture, of the sender, receiver, or their families, has worked pretty
> well.
> If you're good you don't even leave marks.

However, it's not entirely reliable. At some point, the suspect tells you
what you want to hear, whether or not it is the truth, just so you leave
him alone. It can even happen that the suspect convinces himself that what
he really did what he was supposed to do.

Of course, the solved-crimes statistics doesn't care about this subtle
difference.

This brings another ofren underestimated problem into the area of
cryptosystem design, the "rubberhose resistance".

Behavior pattern recognition

[Thomas Shaddack]

http://us.cnn.com/2004/TRAVEL/04/16/airline.behavior.ap/
http://www.usatoday.com/travel/news/2004-04-16-behaviorscan_x.htm
http://news.bostonherald.com/national/view.bg?articleid=1780

Carnival Booth, anyone?

Besides, it's matter of time until the checklists "leak" and the
"adversaries" adjust their behavior accordingly. (What would be the next
move then?).

The "anyone observing security methods" is the funniest part. I am not
certain how one can avoid it, given the amount of time to kill that's
usually present on the airports (is killing time a terrorist act?) -
sooner or later all the tiles on the floor and the panels on the ceiling
are counted, and what's left to watch is the guards and the cameras.
Wouldn't it be less prone to false positives if they would optimize the
airport operations so people won't have to stay there long enough to get
bored and start noticing the security holes?

Idea: Offshore gambling as gateway between real and electronic money

[Thomas Shaddack]

Adoption of anonymous e-money is to great degree hindered by the lack of
infrastructure to convert this currency to/from "meatspace" money.
However, there is possible a method, using offshore gambling companies.

There may be a special kind of "gamble", that looks from the "outside"
like regular betting, but where the participants to certain degree know
the betting results, allowing use of their "e-money" to gain insight into
the "game" - using "meatspace" money as a bet and "e-money" to buy the
knowledge of cards/numbers/whatever in the value of the e-money that
allows a sure win of that amount.

In other words: Without use of the e-money, the game is a "normal" game,
with appropriate probability of win. With the e-money, the player can buy
the 100%-certain win of a given value.

Conversely, a "rigged game" with 0%-probability of win could be used for
depositing the "real" money and converting them to "e-money".

Is this approach possible?
Is this approach feasible?
Where are the hidden problems there?

Anonymity vs reputation question

[Thomas Shaddack]

Thinking about something, I found an interesting problem. It is possible
to set up a reputation-based system with nyms, where every nym is an
identity with attached reputation.

The problem is, a nym that exists for a long time can get its anonymity
partially or fully compromised. Abandonment of the nym and using a blank
one leads to loss of the reputation and related credibility.

Is it possible to have a system where nyms can share reputation without
divulging the links between them? That would allow the possibility of eg.
publishing as a "new" identity while still having the "weight" of an
already established seasoned professional.

I suppose this problem is already known and maybe even solved. Am I
correct?

Re: On Killing Blaster

[Thomas Shaddack]

On Mon, 12 Apr 2004, Major Variola (ret) wrote:

> >against "Men with Guns"...in the end Men With Guns will probably try to
> >shoot away bits, but it's not going to work too well.
>
> You forget that there are no bits which are not physical.  Physical
> things reside on land leased from the State (try not paying your
> real estate taxes).  All cables make a landing somewhere.

Then the magic has to be in making the "bad" bits indistinguishable from
the "good" bits. Any crackdown that would have to net more than a
minuscule fraction of the "bad" ones would then take disproportionate
amount of false positives.

In effect, using the luser population of the Net as a human shield. At
least they will be finally good for something.

> >the edges, until the core is exposed.
>
> Where are you going to buy your hardware from, that it can't be
> shut down?

Dual-use technologies. Repurpose of "consumer-grade" off-the-shelf
devices. Shutting down all the PC hardware vendors would be too unpopular
move to pass. Microcontroller and FPGA suppliers are a bit different, as
there is less demand for them between the plebs, but both the vendors and
the customers would get pretty annoyed if somebody would try to pass such
measure. Not mentioning the adverse impact on "legitimate" innovation, the
suboptimal efficiency of such measure, and the vibrant black market
segment that would get created. Smuggled shipments of chips, black market
with software - but all this was already described in better or worse way
in many cyberpunk fiction books.

> How are you going to hide your TX from the DXing white vans?

Use directional optical links? See eg. http://ronja.twibright.com/ for an
open-source one. Still possible to find and eavesdrop on, but much more
difficult than radio link, and outside of the jurisdiction of FCC.
Optionally, use technology that's so common it doesn't raise eyebrows;
Fry's is full of toys.

Recent developments in consumer wireless tech also allow some toys in the
area of "proximity computing" (as I call it). Just carry a PDA in your
pocket, sit for a while next to the right person, and then find the
required files in the PDA later. Nothing more than passing presence in the
same space without any visible interaction between the two people is
recorded in the security cams (and in eg. a subway it has not much meaning
anyway), no call records in the phone switchboards. Again, nothing that a
prepared adversary can't defeat, but as long as you're still under the
radar, you are likely to be missed by fishing expeditions.

We will need four things in the future: creative use (or non-use) of
available technology, knowledge of the Adversary, improvisation skills,
and - most important - luck.