Tools for anonymous blogging

[Dylan Knobold]

Greetings cryptographers,

   I would like to ask your assistance in setting up a weblog that
cannot easily be traced to my real identity. I have surveyed the
existing tools and do not find one that fits my needs well. For my
proposed blog, I would graciously accept volunteer hosting, but I
think it's also worth thinking improving tools so anonymous blogging
can be accessible to many.

   Of the many forms of Internet communication, blogs have many
desirable properties which interact well with anonymity. Perhaps
most important, the basic blog form is essentially invulnerable to
spam. Any idiot can put their blog up on the Web (and many do), but
nobody is forced to read it. Email, by contrast, is fertile ground
for spam and other similar forms of abuse. Indeed, the anonymous
remailer network had to deal with spam as a serious problem long
before it became the everyday bane it is today.

   Similarly, while running a remailer "exit node" can lead to
significant negative consequences from recipients of abuse, openly
running a proxy to make anonymous blogs accessible to the public
Internet is above reproach, at least among those who believe that
speech should be free.

   Publishing a blog can be relatively high in latency, and very low
in bandwidth, at least by today's standards. I believe these
properties should make it relatively easy to design a blog publishing
protocol which is highly resistant to surveillance. Real-time
Pipenet-style systems, such as ZKS Freedom and Onion Routing, are
susceptible to a listener simply correlating bursts of activity
between the publicly visible blog and the user's bandwidth to the
Internet.

   Finally, while remailers contend against the deeply entrenched
email infrastructure, blog publishing tools are still in their
infancy, and most people do not find it particularly convenient to
publish a blog. In addition, good hosting costs money; the free
hosting services are ad-ridden, in many cases badly.

   Given these goals, what tools are available today? The most obvious
is to use an anonymizing Web proxy such as anonymizer.com in
conjunction with a public blog hosting service such as LiveJournal.
However, this approach doesn't give me a warm and fuzzy feeling.  In
particular, anonymizer.com is a single point of vulnerability, a
one-stop shop if you will for spy agencies, conveniently pre-filtered
to include only those who feel that leaking identity information is
worth thirty bucks a year to protect (the free version is little more
than a teaser for the pay service).

   Another possibility is to leverage the existing email
infrastructure, for example Yahoo Groups. However, while posting to
such a group should be reasonably straightforward using an anonymous
remailer, it's not clear that admin functions are similarly
accessible. Also, such an approach is vulnerable to many attacks
deriving from email's lack of authentication. Finally, I don't
consider an email list to be a particularly high-quality blog format.
I'm not asking for all the frills, but reverse chronological display,
permalinks, and an RSS feed are all essential today.

   Am I missing something? Is there perhaps another good approach
to anonymous blog publishing? If so, I'd appreciate your insight.

   In the meantime, here is how my ideal hosting would work. I'd
arrange (via email) with a volunteer to host my blog. She'd get my
GPG public key, and I would assign me an email address for sending my
updates. That address would route to a script which would decrypt
incoming messages, verify that the signature matches my PK, and
immediately drop any non-conforming emails at that point.

   The contents of a signed email message are then passed to some kind
of "untar" script, which simply replaces files in a public Web
directory. I'm a little unsure about the use of tar itself - it
_should_ be secure, but is fairly crufty by now, and is not usually
considered a security-critical utility (in fact, it's disturbing that
the obvious .. path attack wasn't fixed until GNU tar 1.13.19, see
CAN-2001-1267). Perhaps there is another archive unpacking tool in
which the volunteer has more confidence, or perhaps a very simple, and
thus easily auditable, script, could serve. I'd be more than happy to
write such a script.

   On the posting side, any tool that produces "baked" pages, such as
Blosxom, should serve. It should be relatively easy to integrate the
blog-posting tool with GPG and premail, so that the updates are
automatically signed, anonymized, and sent.

   This is a "quick and dirty" approach which should get blogs online
reasonably easily. If it works well, others should be able to use it.
If enough good anonymous blogs go online, that should help motivate
the design of much more sophisticated tools, possibly using techniques
such as IBM's YouServ to replicate content and thus reduce the
dependence on particular proxy nodes.

   My own blog will probably serve as an example both for those who
feel that anonymous spe

[IP] Inter-University Competition in Information Assurance

[R. A. Hettinga]

--- begin forwarded text


Status: RO
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 11 Mar 2003 02:27:40 -0500
Subject: [IP] Inter-University Competition in Information
Assurance
From: Dave Farber <[EMAIL PROTECTED]>
To: ip <[EMAIL PROTECTED]>
Sender: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]


From: tim finin <[EMAIL PROTECTED]>
Subject: Inter-University Competition in Information Assurance
To: [EMAIL PROTECTED]
Date: Mon, 10 Mar 2003 21:30:44 -0500
Organization: UMBC http://umbc.edu/

Dave -- IPers in the Baltimore-Washington area might be interested
in this talk. Tim
--
  2003 CAPITAL-AREA SEMINAR ON INFORMATION ASSURANCE
  UMBC Center for Information Security and Assurance
   University of Maryland, Baltimore County

   An Inter-University Competition in Information Assurance:
 The Cyber Defense Exercises

   Lt. Colonel Dan Ragsdale
U.S. Military Academy, West Point, NY

 Friday 14 March 2003
   Lunch 11:30, Skylight Lounge, UMBC Commons
Talk 1:00pm, Lecture Hall V, Engineering and Computer Science

During the spring of 2001 and 2002, student teams at the five United
States Service Academies participated in a Cyber Defense Exercise
(CDX).  Prior to each exercise an identical network of servers and
workstations was set up at each school.  During the first phase, teams
of cadets and midshipmen at each site installed and configured an
assortment of required services.  The goal for each team during this
phase was to configure the required service and the underlying
operating systems in the most secure manner possible.  In the second
phase, an NSA-led penetration team attacked each site.  This team "Red
Team," conducted detailed reconnaissance and voluminous attacks over a
five-day period.  They maintained accurate records of any and all
successful penetrations.  A "White Team" from CERT at Carnegie Mellon
University refereed the exercise; they served as observers and
controllers and, using an agreed upon scoring system, determined which
school won.  Personal observation and interviews with students and
faculty show that the CDX is an extraordinary educational
experience. This talk will address in detail some of the benefits and
challenges of conducting such an exercise.

Lt. Colonel Dan Ragsdale is director of the Information Technology and
Operations Center (ITOC) at the US Military Academy (USMA) at West
Point, NY.  He has over twenty-one years of military and information
technology experience, including seven years in the area of
Information Assurance (IA).  This past summer, Lt. Colonel Ragsdale
participated in Operation Enduring Freedom in Afghanistan, where he
served as the Chief of Assessment for the Combine and Joint Task Force
(CJTF-80).  In addition, he has been a frequent speaker and panelist
at national IA conferences, and he has published numerous articles on
IA topics.  He earned a PhD from Texas A&M.  His current research
interests include information assurance, network security, intrusion
detection, and artificial intelligence

Host: Dr. Alan T. Sherman, [EMAIL PROTECTED], Director, UMBC CISA.
http://cisa.umbc.edu/.  Directions: Take Exit 47B off I-95, and follow
signs to UMBC.  Park in visitor's lot.


--


-
You are subscribed as [EMAIL PROTECTED]
To manage your subscription, go to
  http://v2.listbox.com/member/?listname=ip

Archives at: http://www.interesting-people.org/archives/interesting-people/

--- end forwarded text


-- 
-
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]

Re: Encryption of data in smart cards

[Werner Koch]

On Tue, 11 Mar 2003 10:39:17 +0530, N Raghavendra said:

> Can anyone point me to sources about encryption of data in smart
> cards. What I am looking for is protocols for encrypting sensitive
> data (e.g., medical information about the card-holder), so that

Usually you don't need to encrypt data stored on a card. The files on
the card (where you store the data) are protected by ACLs or whatever
the card application provides for this.  If you want to encrypt the
data on the card, you also need to store the key on it. And well, if
you are able to read out the data, you are also able to read out the
key (more or less trivial for most mass market cards).

If you fear an eavesdropper between the box generating the data and
the actual smartcard, one uses secure messaging to protect against
this.  See your card's OS manual (or ISO 7816-8) on how to do it.

If your are talking about memory cards, you can use whatever protocol
you would use for encrypting files.


Salam-Shalom,

   Werner


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

Groove shills for the DoD: Kapor quits board

[Steve Schear]

Software Pioneer Quits Board of Groove
By JOHN MARKOFF
SAN FRANCISCO, March 10 — Mitchell D. Kapor, a personal computer industry 
software pioneer and a civil liberties activist, has resigned from the 
board of Groove Networks after learning that the company's software was 
being used by the Pentagon as part of its development of a domestic 
surveillance system.

http://www.nytimes.com/2003/03/11/business/11PRIV.html

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

Re: Proven Primes

[Nomen Nescio]

Tom St Denis writes:
> What is the benefit of having leading/trailing bits fixed?  As far as I
> know it doesn't make any form of index calculus attack any harder to
> apply.

The Handbook of Applied Cryptography, http://www.cacr.math.uwaterloo.ca/hac/,
has a chapter on efficient implementations which might provide some
insight.

You can take advantage of the left FFF's by using the modular reduction
algorithm described in section 14.3.4 of the HAC.  This is good for the
case where the modulus is slightly less than a power of 2.  Or you can
take advantage of the right FFF's by using Montgomery exponentiation,
described in section 14.3.2 of the HAC and also in algorithm 14.94.
Montgomery multiplication uses a value m' = - m^(-1) mod b, where m is
the modulus and b is the bignum base, typically 2^32 or 2^64.  With these
moduli m' becomes 1, simplifying the calculations.

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

Re: Proven Primes

[Tero Kivinen]

tom st denis writes:
> 0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a439d
> What is the benefit of having leading/trailing bits fixed?

Those primes are generated using the rules defined in the RFC 2412.

> As far as I know it doesn't make any form of index calculus attack
> any harder to apply.

High order bits makes classical remainder algorithms faster, and low
order bits helps the Mongomery-style algoritms.

>From the RFC 2412:
--
   Classical Diffie-Hellman Modular Exponentiation Groups

   The primes for groups 1 and 2 were selected to have certain
   properties.  The high order 64 bits are forced to 1.  This helps the
   classical remainder algorithm, because the trial quotient digit can
   always be taken as the high order word of the dividend, possibly +1.
   The low order 64 bits are forced to 1.  This helps the Montgomery-
   style remainder algorithms, because the multiplier digit can always
   be taken to be the low order word of the dividend.  The middle bits
   are taken from the binary expansion of pi.  This guarantees that they
   are effectively random, while avoiding any suspicion that the primes
   have secretly been selected to be weak.

   Because both primes are based on pi, there is a large section of
   overlap in the hexadecimal representations of the two primes.  The
   primes are chosen to be Sophie Germain primes (i.e., (P-1)/2 is also
   prime), to have the maximum strength against the square-root attack
   on the discrete logarithm problem.

   The starting trial numbers were repeatedly incremented by 2^64 until
   suitable primes were located.

   Because these two primes are congruent to 7 (mod 8), 2 is a quadratic
   residue of each prime.  All powers of 2 will also be quadratic
   residues.  This prevents an opponent from learning the low order bit
   of the Diffie-Hellman exponent (AKA the subgroup confinement
   problem).  Using 2 as a generator is efficient for some modular
   exponentiation algorithms.  [Note that 2 is technically not a
   generator in the number theory sense, because it omits half of the
   possible residues mod P.  From a cryptographic viewpoint, this is a
   virtue.]
-- 
[EMAIL PROTECTED]
SSH Communications Security  http://www.ssh.fi/
SSH IPSEC Toolkithttp://www.ssh.fi/ipsec/

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

Re: Active Countermeasures Against Tempest Attacks

[Gregory Hicks]

> Date: Mon, 10 Mar 2003 23:43:28 -0800
> From: Bill Stewart <[EMAIL PROTECTED]>
> 
> At 09:14 AM 03/10/2003 -0500, Arnold G. Reinhold wrote:
> >On the other hand, remember that the earliest Tempest systems
> >were built using vacuum tubes. An attacker today can carry vast amounts
[...snip...]
> 
> Basically, if you've got a serious threat of TEMPEST attacks,
> you've got serious problems anyway...

Actually, quite a bit of the TEMPEST framework is not stopping an
adversary from reading what you have on your CRT (or display), but
denying the adversary the wherewithal for figuring out that you ARE
there.

It would really be the pits to have someone standing off over the
horizion and saying...  "Hm-m-m...  70Mhz over THERE?  Why is a monitor
over THERE?  There shouldn't be ANYTHING over THERE...  Hm-m-m..  Who
do we know that uses..."  Well, you get the idea.

TEMPEST equipment is specially shielded so that it does not leak ANY RF
energy that can be picked up on RF direction finding equipment.

---
Gregory Hicks| Principal Systems Engineer
Cadence Design Systems   | Direct:   408.576.3609
555 River Oaks Pkwy M/S 6B1  | Fax:  408.894.3400
San Jose, CA 95134   | Internet: [EMAIL PROTECTED]

"The trouble with doing anything right the first time is that nobody
appreciates how difficult it was."

When a team of dedicated individuals makes a commitment to act as
one...  the sky's the limit.

Just because "We've always done it that way" is not necessarily a good
reason to continue to do so...  Grace Hopper, Rear Admiral, United
States Navy


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

Re: Proven Primes

[Jeroen C. van Gelderen]

On Tuesday, Mar 11, 2003, at 11:28 US/Eastern, tom st denis wrote:

--- Tero Kivinen <[EMAIL PROTECTED]> wrote:
SOPHIE GERMAIN PRIME SEARCH
FIXED 64 bits.
INDEX 0:
PRIME (bits 512), index = 131, 0.989151 seconds:
0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bb 
ea63b139b22514a08798e3404ddef9519b3cd3a439d

What is the benefit of having leading/trailing bits fixed?  As far as I
know it doesn't make any form of index calculus attack any harder to
apply.
Performance.

See RFC 2412, Appendix E.

http://www.ietf.org/rfc/rfc2412.txt

-J

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

Re: Proven Primes

[Anton Stiglic]

- Original Message -
From: "tom st denis" <[EMAIL PROTECTED]>
To: "Cryptography" <[EMAIL PROTECTED]>
Sent: Tuesday, March 11, 2003 11:28 AM
Subject: Re: Proven Primes


>
> --- Tero Kivinen <[EMAIL PROTECTED]> wrote:
> > SOPHIE GERMAIN PRIME SEARCH
> > FIXED 64 bits.
> > INDEX 0:
> > PRIME (bits 512), index = 131, 0.989151 seconds:
> >
>
0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b
139b22514a08798e3404ddef9519b3cd3a439d
>
> What is the benefit of having leading/trailing bits fixed?  As far as I
> know it doesn't make any form of index calculus attack any harder to
> apply.

No, but you can speed up modulo multiplication.  The OAKLEY RFC
says:
   The high order 64 bits are forced to 1.  This helps the
   classical remainder algorithm, because the trial quotient digit can
   always be taken as the high order word of the dividend, possibly +1.
   The low order 64 bits are forced to 1.  This helps the Montgomery-
   style remainder algorithms, because the multiplier digit can always
   be taken to be the low order word of the dividend.

At one point in time some of my colleagues got the optimization with the
high order bits set to 1 in C code going on very well, I don`t remember if
we implemented the optimization with the low order bits set to 1.

--Anton



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

Re: Proven Primes

[tom st denis]

--- Tero Kivinen <[EMAIL PROTECTED]> wrote:
> SOPHIE GERMAIN PRIME SEARCH
> FIXED 64 bits.
> INDEX 0: 
> PRIME (bits 512), index = 131, 0.989151 seconds: 
>
0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a439d

What is the benefit of having leading/trailing bits fixed?  As far as I
know it doesn't make any form of index calculus attack any harder to
apply.

Tom

__
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com

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

Re: Active Countermeasures Against Tempest Attacks

[Arnold G. Reinhold]

At 11:43 PM -0800 3/10/03, Bill Stewart wrote:
At 09:14 AM 03/10/2003 -0500, Arnold G. Reinhold wrote:
On the other hand, remember that the earliest Tempest systems
were built using vacuum tubes. An attacker today can carry vast amounts
of signal processing power in a briefcase.
And while some of the signal processing jobs need to scale with the 
target systems,
as computer clock speeds get faster, the leakage gets higher and
therefore shielding becomes harder and leakage gets higher.
Most of the older shielding systems can do fine with the 70 MHz 
monitor speeds,
but the 3 GHz CPU clock speed is more leaky.  Millimeter wavelengths are
_much_ more annoying.
All in all I would not put much faith in ad hoc Tempest protection. 
Without access to the secret specifications and test procedures, I 
would prefer to see highly critical operations done using battery 
powered laptops operating in a Faraday cage, with no wires crossing 
the boundary (no power, no phone, no Ethernet, nada).  In that 
situation, one can calculate shielding effectiveness from first 
principles. 
http://www.cs.nps.navy.mil/curricula/tracks/security/AISGuide/navch16.txt 
suggests US government requirements for a shielded enclosure are 60 
db minimum.
Back when most of the energy lived at a few MHz, it was easy to make 
enclosures
that had air vents that didn't leak useful amounts of signal.  It's 
harder today.
So take your scuba gear into your Faraday cage with you :-)
One of my pet ideas is to used older, 1990's vintage, laptops for 
secure processing, e.g. reading PGP mail, generating key pairs, 
signing submaster keys, etc.  They are cheap enough to dedicate to 
the task, they'd be off most of the time thereby reducing 
vulnerability, older operating systems and firmware have fewer 
opportunities for mischief and most viruses won't run on the old 
software.  Easier shielding due to lower clock rate is an advantage I 
hadn't thought of before.

Basically, if you've got a serious threat of TEMPEST attacks,
you've got serious problems anyway...
You could say that about strong crypto in general. Anyone with 
valuable information stored on a computer has lots to worry about.

Arnold Reinhold

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

Khalid Sheikh Mohammed caught partially by Echelon?

[Perry E. Metzger]

The guardian reports (unsurprisingly) that Echelon was used in
tracking Khalid Sheikh Mohammed's mobile phones:

http://www.guardian.co.uk/alqaida/story/0,12469,911860,00.html

-- 
Perry E. Metzger[EMAIL PROTECTED]

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

Re: Proven Primes

[Tero Kivinen]

Ben Laurie writes:
> > I actually just finished finding the 16384 bit Diffie-Helman group
> > with same kind of parameters. It took about 9.5 months to generate.
> > The 12288 bit group took only about 15 days to generate.
> I have to admit to surprise at the time involved - what s/w are you 
> using to do the generating?

We have our own software and crypto library to generate those primes.
To create ~500 bit group it takes about 10 seconds. To create ~1000
bit group it takes about minute. Here are ike style primes between
512-1024 where the bits is incremented by 32 every time. These are not
proven, but running primo or similar on them shouldn't take that long,
so you can do it yourself if you need a proven prime:

SOPHIE GERMAIN PRIME SEARCH
FIXED 64 bits.
INDEX 0: 
PRIME (bits 512), index = 131, 0.989151 seconds: 
0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a439d
PRIME (bits 544), index = 11486, 2.32198 seconds: 
0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b374a
PRIME (bits 576), index = 145480, 17.2525 seconds: 
0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df2614c7e
PRIME (bits 608), index = 37293, 5.66688 seconds: 
0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1c719
PRIME (bits 640), index = 335775, 42.4739 seconds: 
0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d56e1e3
PRIME (bits 672), index = 5214, 2.83781 seconds: 
0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485c9d3
PRIME (bits 704), index = 65808, 10.8744 seconds: 
0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625f7fd5
PRIME (bits 736), index = 229946, 34.0901 seconds: 
0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44fc522
PRIME (bits 768), index = 149686, 24.5593 seconds: 
0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a63a3620
PRIME (bits 800), index = 168625, 28.5964 seconds: 
0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0c01ef66
PRIME (bits 832), index = 13056, 5.62474 seconds: 
0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406eaec
PRIME (bits 864), index = 173063, 32.9709 seconds: 
0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee3b1001
PRIME (bits 896), index = 26718, 9.01863 seconds: 
0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a8a0802
PRIME (bits 928), index = 636907, 119.4 seconds: 
0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5aea8dbfb
PRIME (bits 960), index = 139761, 31.0893 seconds: 
0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4d41d6
PRIME (bits 992), index = 15349, 8.29022 seconds: 
0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe64928a245

FINISHED (0 primes found in the interval 512 to 1024).
-- 
[EMAIL PROTECTED]
SSH Communications Security  http://www.ssh.fi/
SSH IPSEC Toolkithttp://www.ssh.fi/ipsec/

-
The Cryptography Mailing List
Unsubscribe by sending "unsubs

Re: double shot of snake oil, good conclusion

[Hagai Bar-El]

Tal,

I am in full agreement with your opinion. I do not think security is an 
"all or nothing" property, and I do think that mechanisms can be considered 
effective even if they do not protect against attackers with some level of 
skill or motivation. After all, there is no complete security and security 
is, and has always been, considered as "perceived assurance".

I do not think that a fact that a mechanism can be somehow circumvented 
makes it useless. "Keepng the honest people honest" is a good enough 
legitimation for a mechanism to exist as well as "moving the bar higher". 
However, the only problem I can see in this case is the opening of a 
possibility of a false sense of security. Security mechanisms do not have 
to be perfect, but their perceived strength by their users shall be set right.

For this I personally think that the mechanism is great and useful, but 
should be presented by Microsoft accordingly, hence: as a useful 
security-related feature, not as a complete bullet-proof protection tool.

Hagai.

Hagai Bar-El - Information Security Analyst
Tel.: 972-8-9354152  Fax.: 972-8-9354152
E-mail: [EMAIL PROTECTED]  Web: www.hbarel.com


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

Re: Active Countermeasures Against Tempest Attacks

[Bill Stewart]

At 09:14 AM 03/10/2003 -0500, Arnold G. Reinhold wrote:
On the other hand, remember that the earliest Tempest systems
were built using vacuum tubes. An attacker today can carry vast amounts
of signal processing power in a briefcase.
And while some of the signal processing jobs need to scale with the target 
systems,
as computer clock speeds get faster, the leakage gets higher and
therefore shielding becomes harder and leakage gets higher.
Most of the older shielding systems can do fine with the 70 MHz monitor speeds,
but the 3 GHz CPU clock speed is more leaky.  Millimeter wavelengths are
_much_ more annoying.

All in all I would not put much faith in ad hoc Tempest protection. 
Without access to the secret specifications and test procedures, I would 
prefer to see highly critical operations done using battery powered 
laptops operating in a Faraday cage, with no wires crossing the boundary 
(no power, no phone, no Ethernet, nada).  In that situation, one can 
calculate shielding effectiveness from first principles. 
http://www.cs.nps.navy.mil/curricula/tracks/security/AISGuide/navch16.txt 
suggests US government requirements for a shielded enclosure are 60 db minimum.
Back when most of the energy lived at a few MHz, it was easy to make enclosures
that had air vents that didn't leak useful amounts of signal.  It's harder 
today.
So take your scuba gear into your Faraday cage with you :-)

Basically, if you've got a serious threat of TEMPEST attacks,
you've got serious problems anyway...
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Encryption of data in smart cards

[N. Raghavendra]

Hello,

Can anyone point me to sources about encryption of data in smart
cards. What I am looking for is protocols for encrypting sensitive
data (e.g., medical information about the card-holder), so that
even if the card falls into malicious hands, it won't be easy to
read that data.

Thank you,
Raghavendra.


-- 
N. Raghavendra <[EMAIL PROTECTED]> | OpenPGP public key available
Tata Consultancy Services| at http://www.keyserver.net/
Hyderabad|  Key ID: 0x03618806

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

New release of Invisible IRC available

[Steve Schear]

 IIP 1.1.0 (stable) is released. (2003-03-10)

Invisible IRC Project is a three-tier, peer distributed network designed to 
be a secure and private transport medium for high speed, low volume, 
dynamic content. Features:

* Perfect Forward Security using Diffie-Hellman Key Exchange Protocol
* Constant session key rotation
* 128 bit Blowfish node-to-node encryption
* 160 bit Blowfish end-to-end encryption
* Chaffed traffic to thwart traffic analysis
* Secure dynamic routing using cryptographically signed namespaces for 
node identification
* Node level flood control
* Seamless use of standard IRC clients
* Gui interface
* Peer distributed topology for protecting the identity of users
* Completely modular in design, all protocols are plug-in capable

The IIP software is released under the GPL license and is available for 
Windows 98/ME/NT/2000/XP, *nix/BSD and Mac OSX.

http://invisiblenet.net/

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