Re: Blinky Rides Again: RCMP suspect al-Qaida messages

[Florian Weimer]

* Adam Shostack:

> On Sat, Dec 11, 2004 at 10:24:09PM +0100, Florian Weimer wrote:
> | * R. A. Hettinga quotes a news article:
> | 
> | >  There have been numerous media reports in recent years that terrorist
> | > groups, including al-Qaida, were using steganographic techniques.
> | 
> | As far as I know, these news stories can be tracked back to a
> | particular USA Today story.  There's also been a bunch of stories how
> | a covert channel in TCP could be used by terrorists to hide their
> | communication.
>
> There's very good evidence that Al Qaida does *not* use strong crypto.

However, they use some form of crypto.  From a recent press release of
our attorney general:

| Als mitgliedschaftliche Betätigung im Sinne der Strafvorschrift des §
| 129b StGB für die "Ansar al Islam" wird den Beschuldigten vor allem
| zur Last gelegt, einen Mordanschlag auf den irakischen
| Ministerpräsidenten während seines Staatsbesuches in Deutschland am
| 2. und 3. Dezember 2004 geplant zu haben. Dies ergibt sich aus dem
| Inhalt einer Vielzahl zwischen den Beschuldigten seit dem 28. November
| 2004 verschlüsselt geführter Telefongespräche



(Very rough translation: "The persons are accused of being members of
"Ansar al Islam" and planning the assassination of the Iraqi prime
minister during his visit to Germany on the 2nd and 3rd December,
2004.  This follows from the contents of a multitude of encrypted
telephone calls the accussed exchanged since November 28, 2004.")

Probably, they just used code words, and no "real" cryptography.  I'm
trying to obtain a confirmation, though.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Blinky Rides Again: RCMP suspect al-Qaida messages

[John Kelsey]

>From: Adam Shostack <[EMAIL PROTECTED]>
>Sent: Dec 11, 2004 4:52 PM
>Subject: Re: Blinky Rides Again: RCMP suspect al-Qaida messages

...
>It seems consistent that Al Qaeda prefers being 'fish in the sea' to
>standing out by use of crypto. Also, given the depth and breadth of
>conspiracies they believe in, it seems that they might see all us
>cryptographers as a massive deception technique to get them to use bad
>crypto. (And hey, they're almost right! We love that they use bad
>crypto.)

They're going to have the same problems as the rest of us using strong 
cryptography--configuration and usability problems, key management hassles, 
incompatibilities between versions and programs, etc.  They have to do this 
with no central authority, no single support line or person who can reliably 
start things up and help them, in a basically decentralized way.  The 
cypherpunkish idea of a decentralized conspiracy using strong crypto only works 
if either the tools are a lot easier to use, or if the conspiracy is made up of 
cryptographically sophisticated people.  AQ is presumably made up of people who 
know a lot about the Koran, and probably a lot about day-to-day operational 
security against the Pakistani or Indonesian secret police, but there's not 
much reason to think they are very sophisticated about cryptography.  If you 
can't get most computer-literate people you know to use PGP to send you e-mail, 
how well is it going to work to do with a bunch of random jihadis?

-John

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Toshiba shows practical quantum cryptography

[R.A. Hettinga]

Toshiba shows practical quantum cryptography
Rupert Goodwins
ZDNet UK
December 13, 2004, 18:15 GMT

Toshiba Research Europe demonstrated last week what it claims is the
world's first reliable automated quantum cryptography system and run it
continuously for over a week.

 The system, which relies on single photons to transmit an untappable key
over standard optical fibres, is capable of delivering thousands of keys a
second and can be effective over distances of more than 100km.

 Although no price or launch date has been set yet, Toshiba is already in
talks with a number of telcos and end users in preparation for
commercialisation of the technology -- which offers the possibility of
significantly more secure networking.

 "We're talking to a number of potential end users at the minute," Dr
Andrew Shields, group leader of Toshiba's Cambridge-based Quantum
Information Group told ZDNet UK. "We're planning to do some trials in the
City of London next year, and are targeting users in the financial sector.
We've also had some interest from telcos, including MCI with whom we've
been running the installed fibre tests."

 The system works by transmitting a long stream of photons modulated to
represent ones and zeros, most of which are lost along the way. These
photons can be modulated in one of two ways through two different kinds of
polarisation, but according to Heisenberg's Uncertainty Principle it is
impossible to know both the kind of polarisation and the data represented
by the photon. The receiver has to assume one to get the other, which it
will frequently get wrong.

 The receiver picks up and attempts to decode a few out of those that make
it, and reports back to the sender which ones it received and decoded thus
making up a key that both ends know. Any interceptor can't know what the
value of those photons is, because by reading them in transit it will
destroy them, and it can't replace them after reading them because it can
never know their exact details.

 Although Toshiba has been developing special hardware to create and
analyse single photon transactions by quantum dots -- effectively
artificial atoms integrated with control circuitry -- the current
cryptographic equipment uses standard parts, including Peltier-effect
cooled detectors operating at very low noise levels. The next generation of
equipment is expected to use this new technology.

 Toshiba is also looking at ways to increase the range of the systems
beyond the limitations of a single fibre -- because a photon can't be
intercepted and retransmitted, it's not possible for the technology to
incorporate repeaters to overcome the losses in multiple segments. However,
says Shields, there is a possibility that repeaters may be created using
quantum teleportation -- a new and still experimental effect where the
quantum state of a particle can be transmitted across distances without it
needing to be fully measured.

 Toshiba Research Europe Ltd is part of the European SECOQC project, which
is working towards the development of a global network for secure
communication using quantum technology.


-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

DIMACS Workshop on Security of Web Services and E-Commerce

[Linda Casals]

Call for Participation Deadline January 17, 2005
***

DIMACS Workshop on Security of Web Services and E-Commerce

 May 5 - 6, 2005 
 DIMACS Center, Rutgers University, Piscataway, NJ


Organizer: 

  Brian LaMacchia, Microsoft, [EMAIL PROTECTED] 
   
Presented under the auspices of the Special Focus on Communication
Security and Information Privacy.



 The growth of Web Services, and in particular electronic commerce
activities based on them, is quickly being followed by work on Web
Services security protocols. While core XML security standards like
XMLDSIG, XMLENC and WS-Security have been completed, they only provide
the basic building blocks of authentication, integrity protection and
confidentiality for Web Services. Additional Web Services standards
and protocols are required to provide higher-order operations such as
trust management, delegation, and federation. At the same time, the
sharp rise in "phishing" attacks and other forms of on-line fraud
simply confirms that all our work on security protocols is for naught
if we cannot make it both possible and easy for the average user to
discover when a security property has failed during a
transaction. This workshop aims to explore these areas as well as
other current and future security and privacy challenges for Web
Services applications and e-commerce.


**
Participation:

The workshop will be open to the public (no submission is necessary to
attend). If you'd like to give a presentation please send a title and
abstract to [EMAIL PROTECTED] by January 17, 2005. 
Submissions may describe ongoing or planned work related to the
security of Web Services and electronic commerce, or they may discuss
important research problems or propose a research agenda in this
area. Also, we intend this to be a participatory and interactive
meeting so we hope you will be able to contribute to the meeting even
without giving an announced talk.

*
Registration:

Pre-registration deadline: April 28, 2005

Please see website for complete registration information:
http://dimacs.rutgers.edu/Workshops/Commerce/

*

Information on participation, registration, accomodations, and travel 
can be found at:

http://dimacs.rutgers.edu/Workshops/Commerce/

   **PLEASE BE SURE TO PRE-REGISTER EARLY**



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Tor 0.0.9 is out (fwd from [EMAIL PROTECTED])

[R.A. Hettinga]

--- begin forwarded text


Date: Mon, 13 Dec 2004 09:05:25 +0100
From: Eugen Leitl <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Tor 0.0.9 is out (fwd from [EMAIL PROTECTED])
User-Agent: Mutt/1.4i
Sender: [EMAIL PROTECTED]

From: Roger Dingledine <[EMAIL PROTECTED]>
Subject: Tor 0.0.9 is out
To: [EMAIL PROTECTED]
Date: Sun, 12 Dec 2004 20:51:51 -0500
Reply-To: [EMAIL PROTECTED]

Aside from the many bug fixes, 0.0.9 includes a win32 installer, better
circuit building algorithms, bandwidth accounting and hibernation,
more efficient directory fetching, and support for a separate Tor GUI
controller program (once somebody writes one for us).

tarball:   http://tor.freehaven.net/dist/tor-0.0.9.tar.gz
signature: http://tor.freehaven.net/dist/tor-0.0.9.tar.gz.asc
win32 exe: http://tor.freehaven.net/dist/tor-0.0.9-win32.exe
win32 sig: http://tor.freehaven.net/dist/tor-0.0.9-win32.exe.asc
(use -dPr tor-0_0_9 if you want to check out from cvs)

  o Bugfixes on 0.0.8.1 (Crashes and asserts):
- Catch and ignore SIGXFSZ signals when log files exceed 2GB; our
  write() call will fail and we handle it there.
- When we run out of disk space, or other log writing error, don't
  crash. Just stop logging to that log and continue.
- Fix isspace() and friends so they still make Solaris happy
  but also so they don't trigger asserts on win32.
- Fix assert failure on malformed socks4a requests.
- Fix an assert bug where a hidden service provider would fail if
  the first hop of his rendezvous circuit was down.
- Better handling of size_t vs int, so we're more robust on 64
  bit platforms.

  o Bugfixes on 0.0.8.1 (Win32):
- Make windows sockets actually non-blocking (oops), and handle
  win32 socket errors better.
- Fix parse_iso_time on platforms without strptime (eg win32).
- win32: when being multithreaded, leave parent fdarray open.
- Better handling of winsock includes on non-MSV win32 compilers.
- Change our file IO stuff (especially wrt OpenSSL) so win32 is
  happier.
- Make unit tests work on win32.

  o Bugfixes on 0.0.8.1 (Path selection and streams):
- Calculate timeout for waiting for a connected cell from the time
  we sent the begin cell, not from the time the stream started. If
  it took a long time to establish the circuit, we would time out
  right after sending the begin cell.
- Fix router_compare_addr_to_addr_policy: it was not treating a port
  of * as always matching, so we were picking reject *:* nodes as
  exit nodes too. Oops.
- When read() failed on a stream, we would close it without sending
  back an end. So 'connection refused' would simply be ignored and
  the user would get no response.
- Stop a sigpipe: when an 'end' cell races with eof from the app,
  we shouldn't hold-open-until-flush if the eof arrived first.
- Let resolve conns retry/expire also, rather than sticking around
  forever.
- Fix more dns related bugs: send back resolve_failed and end cells
  more reliably when the resolve fails, rather than closing the
  circuit and then trying to send the cell. Also attach dummy resolve
  connections to a circuit *before* calling dns_resolve(), to fix
  a bug where cached answers would never be sent in RESOLVED cells.

  o Bugfixes on 0.0.8.1 (Circuits):
- Finally fix a bug that's been plaguing us for a year:
  With high load, circuit package window was reaching 0. Whenever
  we got a circuit-level sendme, we were reading a lot on each
  socket, but only writing out a bit. So we would eventually reach
  eof. This would be noticed and acted on even when there were still
  bytes sitting in the inbuf.
- Use identity comparison, not nickname comparison, to choose which
  half of circuit-ID-space each side gets to use. This is needed
  because sometimes we think of a router as a nickname, and sometimes
  as a hex ID, and we can't predict what the other side will do.

  o Bugfixes on 0.0.8.1 (Other):
- Fix a whole slew of memory leaks.
- Disallow NDEBUG. We don't ever want anybody to turn off debug.
- If we are using select, make sure we stay within FD_SETSIZE.
- When poll() is interrupted, we shouldn't believe the revents values.
- Add a FAST_SMARTLIST define to optionally inline smartlist_get
  and smartlist_len, which are two major profiling offenders.
- If do_hup fails, actually notice.
- Flush the log file descriptor after we print "Tor opening log file",
  so we don't see those messages days later.
- Hidden service operators now correctly handle version 1 style
  INTRODUCE1 cells (nobody generates them still, so not a critical
  bug).
- Handle more errnos from accept() without closing the listener.
  Some OpenBSD machines were closing their listeners because
  they ran out of file descriptors.
- Some people had wrapped their tor client/server

RE: Blinky Rides Again: RCMP suspect al-Qaida messages

[James A. Donald]

--
On 9 Dec 2004 at 16:15, J.A. Terranson wrote:
> (3) The other camp believes that stego is a lab-only toy, 
> unsuitable for much of anything besides scaring the shit out 
> of the people in the Satan camp.

I have used stego for practical purposes.  The great advantage
of stego is that it conceals your threat model. 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 aV25L9tGoz00uU3bzcY+rbFDV5nX9BCkK67CRwcd
 4mBXnVakFBPiPRCdugeDolUdtnd8iueWgYFwR3Pch



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]