Re: Cryptography and the Open Source Security Debate

[Jon Callas]

On 10 Aug 2004, at 5:16 AM, John Kelsey wrote:
So, how many people on this list have actually looked at the PGP key 
generation code in any depth?  Open source makes it possible for 
people to look for security holes, but it sure doesn't guarantee that 
anyone will do so, especially anyone who's at all good at it.


The relevant key generation code can be found in:
libs2/pgpsdk/priv/crypto/pubkey/
(those are backslashes on Windows, of course). The RSA key generation, 
for example is in ./pgpRSAKey.c.

You might also want to look at .../crypto/bignum and .../crypto/random/ 
while you're at it.

There is also high-level code in .../crypto/keys/pgpKeyMan.c for public 
key generation.

Incidentally, none of the issues that lrk brought up (RSA key being 
made from an "easy to factor" composite, a symmetric key that is a weak 
key, etc.) are unique to PGP. This should be obvious, but I have to say 
it.

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

Cryptome on ABC Evening News?

[R. A. Hettinga]

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

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

Hydan: Information Hiding in Program Binaries

[R. A. Hettinga]

Hydan [hI-dn]:

Old english, to hide or conceal.


Intro:

Hydan steganographically conceals a message into an
application. It exploits redundancy in the i386 instruction
set by defining sets of functionally equivalent instructions.
It then encodes information in machine code by using the
appropriate instructions from each set.

Features:

- Application filesize remains unchanged
- Message is blowfish encrypted with a user-supplied
  passphrase before being embedded
- Encoding rate: 1/110

Primary uses for Hydan:

- Covert Communication: embedding data into binaries
  creates a covert channel that can be used to
  exchange secret messages.

- Signing: a program's cryptographic signature can
  be embedded into itself. The recipient of the
  binary can then verify that it has not been
  tampered with (virus or trojan), and is really
  from who it claims to be from. This check can be
  built into the OS for user transparency.

- Watermarking: a watermark can be embedded to
  uniquely identify binaries for copyright purposes,
  or as part of a DRM scheme. Note: this usage is not
  recommended as Hydan implements fragile watermarks.

If you think of anything else, do let me know :)


Platforms Supported:

- {Net, Free}BSD i386 ELF
- Linux i386 ELF
- Windows XP PE/COFF


Download:

Version 0.13


News:

Update: I've  finally updated the hydan code, after a long time off.
The encoding rate has been improved to 1/110 (thanks to a tip from
sandeep!), and the code is now much cleaner too. In the mean time,
hydan has been presented at:

CansecWest 04
BlackHat Vegas 04
DefCon 04

A paper is to be published soon as well:
Hydan:  Hiding Information in Program Binaries
Rakan El-Khalil and Angelos D. Keromytis.

Which is to appear in the proceedings of the 6th International
Conference on Information and Communications Security (ICICS),
Malaga, Spain. To be published in Springer Verlag's LNCS.

Hydan was initially presented at CodeCon on 02/23/2003.

The following is a list of articles online from that presentation:

- The Register: Hydan Seek
  (same article at BusinessWeek, and SecurityFocus)
- Slashdot: Program Hides Secret Messages in Executables
  (could it be? crazyboy survived slashdotting?)
- Punto-Informatico: Un tool cela segreti nei programmi
  (intl coverage! been getting a lot of hits from them)
- Bruce Schneier's Crypto-Gram: March 15, 2003 Issue
  (and not in the snake-oil section either ;)


Like my Work?

Buy me books!


Contact:

Rakan El-Khalil 

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

Any TLS server key compromises?

[Marc Branchaud]

I've been wondering, has a TLS server (or client, for that matter) key 
ever actually been compromised?  I don't think I've ever heard of one.

I'm thinking of two possible avenues for compromise, and ignoring 
insider attacks.  One is through defects in the protocol itself or its 
implementation.  The other would be through a compromise of the server 
host (e.g. a buffer overflow in Apache) that allows the attacker to copy 
the TLS server's private key from the file system.

It seems to me that in-the-wild attacks on the protocol or its 
implementation are unheard of.

OTOH, we hear about server break-ins all the time.  However, one never 
hears about these break-ins leading to a compromise of the server's key.

Perhaps the server's private key isn't a really useful target?  Although 
posession of the key makes it easy to spoof a secure server, actually 
doing that spoofing requires a secondary attack, like phishing or an 
active attack on the Internet, to redirect a user to the false server.

So have there ever been any actual TLS private key compromises (through 
any non-insider attack)?

If TLS private keys aren't attractive enough a target for them to be 
compromised even when the opportunity presents itself (as I'm assuming 
it has), then to what extent do these keys really need to be protected?

		M.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Cryptome on ABC Evening News?

[R. A. Hettinga]

--- begin forwarded text


Date: Thu, 12 Aug 2004 20:41:05 -0700
To: [EMAIL PROTECTED]
From: John Young <[EMAIL PROTECTED]>
Subject: Re: Cryptome on ABC Evening News?
Sender: [EMAIL PROTECTED]

There a text version of the report on abcnews.com and a video
is available to subscribers.

To keep the nation secure the web site is not named. Google
search appears to do it based on hate mail coming in.

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

Too Much Information?

[R. A. Hettinga]

 

Too Much Information?
Web Site Raises Questions About Public Access to Sensitive Government Info
By JakeTapper
ABCNEWS.com

Aug. 12, 2004- John Young, a 69-year-old architect, was contacted a few
weeks ago by Department of Homeland Security officials, who expressed
concern about what he was posting on his Web site.

Officials questioned Young about information he had posted about the 2004
Democratic National Convention, including satellite photos of the
convention site and the location of specific police barricades referred to
on the site as "a complete joke."

 In response to a complaint, two special agents from the FBI's
counterterrorism office in New York City interviewed Young in November 2003.

 "They said, 'Why didn't you call us about this? Why are you telling the
public?' And we said, 'Because it's out there and you can see it. You folks
weren't doing anything,' " Young told ABC News.

 The agents, according to Young, stressed they knew that nothing on the
site was illegal. Young added: "They said, 'What we'd like you to do, if
you're approached by anyone that you think intends to harm the United
States, we're asking you to let us know that.' "

 "I know there are a lot of people in the government who find him
troublesome," said former White House terrorism adviser Richard Clarke, now
an ABC News consultant. "There is a real tension here between the public's
right to know and civil liberties, on the one hand, and security on the
other."

 But Young argues his actions enhance national security, since he points
out to the public vulnerabilities the government does not want to
acknowledge.

 Like others who run similar Web sites, Young does so by using information
from the public domain, such as:

 * Photographs of preparations for the upcoming Republican National
Convention at New York City's Madison Square Garden

 * Detailed maps of bridges and tunnels leading in and out of Manhattan

 * Maps of New York City's single natural gas pipeline

 * The location of an underground nuclear weapons storage complex in New Mexico

 Enabling the Enemy?

 "I think it's very, very bad for the country to have anyone putting
together information that makes it easier for anyone that wants to injure
Americans to do so," said Rep. Chris Cox, R-Calif., chair of the House
Homeland Security Committee.

 Law enforcement officials were particularly upset that Young posted the
satellite photos and addresses for the homes of top Bush administration
officials.

 "We think public officials should be totally transparent. There should be
no secrecy," said Young. "We are opposed to government secrecy in all of
its forms."

 Officials call that argument outrageous and argue some secrecy is necessary.

 "The Department of Homeland Security has taken aggressive measures to
protect critical infrastructure across the country," said a Department of
Homeland Security spokeswoman. "We discourage Web posting of detailed
information about critical infrastructure. This information is not helpful
to our ongoing efforts to protect the American people and our nation's
infrastructure."

 When asked how he would respond to those who consider his Web site
unpatriotic since it could provide useful information for those who seek to
harm the United States, Young said, "If this is not done, more Americans
are going to die. More harm is going to come to the United States. It is
more patriotic to get information out than to withhold it."

 Officials acknowledge there is not much they can do; Young has not broken
any laws.

-- 
-
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: Al Qaeda crypto reportedly fails the test

[Aram Perez]

Hi Chris,

> Steven M. Bellovin writes:
> 
>> http://www.petitcolas.net/fabien/kerckhoffs/index.html for the actual
>> articles.)
> 
> Does there exist an English translation (I'd be surprised if not)? If
> not, I'd be happy to provide one if there were sufficient interest.

I'd be interested in an English version.

Thanks!
Aram

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

ONLamp.com: Anonymous, Open Source P2P with MUTE

[R. A. Hettinga]

  Published on ONLamp.com (http://www.onlamp.com/)
  http://www.onlamp.com/pub/a/onlamp/2004/08/12/mute.html
  See this if you're having trouble printing code examples



 Anonymous, Open Source P2P with MUTE
 by Howard Wen
 08/12/2004

 The ongoing battle between users of file-sharing programs and media
copyright-enforcement organizations (most notably the RIAA) has seemingly
become a daily ping-pong match of lawsuits, threats of lawsuits,
countersuits, office raids of commercial P2P services, and soda pop
promotional gimmicks encouraging people to download music from legal music
downloading services.

Regardless of all the threats, intimidation, and spoofed music files
clogging networks, P2P services in which users engage in "copyright
infringement" (or "file sharing," if you prefer) continue to thrive.
Activity on them still far surpasses the traffic of the legal music
download sites, such as iTunes Music Store and the now legit Napster.

One weakness of the P2P networks, including the infamous KaZaA, is the fact
that it's so easy to identify a user's IP address. The Recording Industry
Association of America (RIAA) has managed to use such extracted information
to subpoena ISPs for the identities of potential defendants.

Jason Rohrer has devised what could be the next technological headache for
organizations like the RIAA: a P2P system that can mask the identity (or,
at least, the IP address) of each user connected to it. Figuratively, he's
done it by letting out the ants to ruin the RIAA's picnic.

Rohrer, a 26-year-old programmer from Potsdam, New York, found inspiration
in the way ants stream toward a food source. From observing the creatures'
behavior, he mapped out a networking method that functions similarly -
essentially, a shared file is the food source, and clients on the network
are the ants seeking the food. He then wrote his own P2P program putting
this theory to practice and christened it MUTE. Developed entirely in C++
and released as open source, the program runs on Linux, Win32, and Mac OS X.

Figure 1. The MUTE file-sharing program running on Linux.

Rohrer spoke with me for the O'Reilly Network, explaining how the ways of
the ant could hold the key to anonymity for P2P users.

Howard Wen: Give us a basic technical summary: What's the big difference
between how the MUTE network works versus the traditional P2P method, such
as KaZaA?
Jason Rohrer:Traditional P2P networks can best be described as "direct
download" systems. Nodes are linked together in a "mesh network," with each
node connecting to a small number of neighbors. Certain pieces of
information are broadcast and routed through the mesh, such as search
requests and results. Downloads are not passed through the mesh - the
downloader establishes a new, direct connection to the file source to start
the transfer.

Of course, a direct transmission means that the downloader needs to know
the IP address of the file source. If you use TCP sockets - or UDP packets
- properly, a direct transmission also means that the file source can find
out the downloader's IP address.

The RIAA has demonstrated that, with a subpoena or lawsuit, an IP address
can easily be translated into a human name and postal address. In other
words, any system that relies on direct downloads is not anonymous, due to
intrinsic properties of Internet routing.

A MUTE network is very similar in form to a traditional P2P network: MUTE
nodes connect to each other in a mesh network, with each node maintaining a
small number of direct links to neighbor nodes. In addition to routing
search requests and results through the mesh, MUTE routes everything else,
including file transfers. Thus, a downloader does not need to know the IP
address of a file source, since the downloader never needs to make a direct
connection, and a download is routed through the chain of nodes that
separate the downloader from the file source. Routed downloads are what
separates MUTE from other search-and-download P2P networks.

Of course, routed downloads alone do not provide anonymity. Even more
crucial is the way that MUTE routes messages anonymously. Each MUTE node
generates a random virtual address for itself at startup. Messages are
tagged as being "from" one virtual address and "to" another virtual
address, though only the sending node knows that it owns the "from"
address, and only the receiving node knows that it owns the "to" address.
None of the other nodes in the network know which node owns either of these
addresses.

As messages travel through the network, they leave behind local "scent" -
or routing - information for their "from" address at each node that they
pass through.

For example, if a message from Alice passes through a node, the node
records that it has received messages from Alice from one of its neighbors.
In the future, if that node receives a message to Alice, it can use this
scent to direct the message onward through that neighbor. E

Joux found a collision for SHA-0 !

[Pascal Junod]

Hi !

This has appeared on a french mailing-list related to crypto. The results of 
Joux improve on those of Chen and Biham which will be presented next week at 
CRYPTO'04.

Enjoy !



Thursday 12th, August 2004

We are glad to announce that we found a collision for SHA-0.

First message (2048 bits represented in hex):
a766a602 b65cffe7 73bcf258 26b322b3 d01b1a97 2684ef53 3e3b4b7f 53fe3762
24c08e47 e959b2bc 3b519880 b9286568 247d110f 70f5c5e2 b4590ca3 f55f52fe
effd4c8f e68de835 329e603c c51e7f02 545410d1 671d108d f5a4000d cf20a439
4949d72c d14fbb03 45cf3a29 5dcda89f 998f8755 2c9a58b1 bdc38483 5e477185
f96e68be bb0025d2 d2b69edf 21724198 f688b41d eb9b4913 fbe696b5 457ab399
21e1d759 1f89de84 57e8613c 6c9e3b24 2879d4d8 783b2d9c a9935ea5 26a729c0
6edfc501 37e69330 be976012 cc5dfe1c 14c4c68b d1db3ecb 24438a59 a09b5db4
35563e0d 8bdf572f 77b53065 cef31f32 dc9dbaa0 4146261e 9994bd5c d0758e3d

Second message:
a766a602 b65cffe7 73bcf258 26b322b1 d01b1ad7 2684ef51 be3b4b7f d3fe3762
a4c08e45 e959b2fc 3b519880 39286528 a47d110d 70f5c5e0 34590ce3 755f52fc
6ffd4c8d 668de875 329e603e 451e7f02 d45410d1 e71d108d f5a4000d cf20a439
4949d72c d14fbb01 45cf3a69 5dcda89d 198f8755 ac9a58b1 3dc38481 5e4771c5
796e68fe bb0025d0 52b69edd a17241d8 7688b41f 6b9b4911 7be696f5 c57ab399
a1e1d719 9f89de86 57e8613c ec9e3b26 a879d498 783b2d9e 29935ea7 a6a72980
6edfc503 37e69330 3e976010 4c5dfe5c 14c4c689 51db3ecb a4438a59 209b5db4
35563e0d 8bdf572f 77b53065 cef31f30 dc9dbae0 4146261c 1994bd5c 50758e3d

Common hash value (can be found using for example "openssl sha file.bin"
after creating a binary file containing any of the messages)
c9f160777d4086fe8095fba58b7e20c228a4006b

This was done by using a generalization of the attack presented at Crypto'98
by Chabaud and Joux. This generalization takes advantage of the iterative
structure of SHA-0. We also used the "neutral bit" technique of Biham and
Chen (To be presented at Crypto'2004).

The computation was performed on TERA NOVA (a 256 Intel-Itanium2 system
developped by BULL SA, installed in the CEA DAM open laboratory
TERA TECH). It required approximatively 80 000 CPU hours.
The complexity of the attack was about 2^51.

We would like to thank CEA DAM, CAPS Entreprise and BULL SA for
their strong support to break this challenge.

Antoine Joux(*) (DCSSI Crypto Lab)
Patrick Carribault (Bull SA)
Christophe Lemuet, William Jalby
(Universit'e de Versailles/Saint-Quentin en Yvelines)

(*) The theoretical cryptanalysis was developped by this author.
The three others authors ported and optimized the attack on the TERA NOVA
supercomputer, using CAPS Entreprise tools.

$hexdump fic1.bin
000 66a7 02a6 5cb6 e7ff bc73 58f2 b326 b322
010 1bd0 971a 8426 53ef 3b3e 7f4b fe53 6237
020 c024 478e 59e9 bcb2 513b 8098 28b9 6865
030 7d24 0f11 f570 e2c5 59b4 a30c 5ff5 fe52
040 fdef 8f4c 8de6 35e8 9e32 3c60 1ec5 027f
050 5454 d110 1d67 8d10 a4f5 0d00 20cf 39a4
060 4949 2cd7 4fd1 03bb cf45 293a cd5d 9fa8
070 8f99 5587 9a2c b158 c3bd 8384 475e 8571
080 6ef9 be68 00bb d225 b6d2 df9e 7221 9841
090 88f6 1db4 9beb 1349 e6fb b596 7a45 99b3
0a0 e121 59d7 891f 84de e857 3c61 9e6c 243b
0b0 7928 d8d4 3b78 9c2d 93a9 a55e a726 c029
0c0 df6e 01c5 e637 3093 97be 1260 5dcc 1cfe
0d0 c414 8bc6 dbd1 cb3e 4324 598a 9ba0 b45d
0e0 5635 0d3e df8b 2f57 b577 6530 f3ce 321f
0f0 9ddc a0ba 4641 1e26 9499 5cbd 75d0 3d8e


$ hexdump fic2.bin
000 66a7 02a6 5cb6 e7ff bc73 58f2 b326 b122
010 1bd0 d71a 8426 51ef 3bbe 7f4b fed3 6237
020 c0a4 458e 59e9 fcb2 513b 8098 2839 2865
030 7da4 0d11 f570 e0c5 5934 e30c 5f75 fc52
040 fd6f 8d4c 8d66 75e8 9e32 3e60 1e45 027f
050 54d4 d110 1de7 8d10 a4f5 0d00 20cf 39a4
060 4949 2cd7 4fd1 01bb cf45 693a cd5d 9da8
070 8f19 5587 9aac b158 c33d 8184 475e c571
080 6e79 fe68 00bb d025 b652 dd9e 72a1 d841
090 8876 1fb4 9b6b 1149 e67b f596 7ac5 99b3
0a0 e1a1 19d7 899f 86de e857 3c61 9eec 263b
0b0 79a8 98d4 3b78 9e2d 9329 a75e a7a6 8029
0c0 df6e 03c5 e637 3093 973e 1060 5d4c 5cfe
0d0 c414 89c6 db51 cb3e 43a4 598a 9b20 b45d
0e0 5635 0d3e df8b 2f57 b577 6530 f3ce 301f
0f0 9ddc e0ba 4641 1c26 9419 5cbd 7550 3d8e

$ diff fic1.bin fic2.bin
Binary files fic1.bin and fic2.bin differ

$ openssl sha fic1.bin
SHA(fic1.bin)= c9f160777d4086fe8095fba58b7e20c228a4006b

$ openssl sha fic2.bin
SHA(fic2.bin)= c9f160777d4086fe8095fba58b7e20c228a4006b


-- 
~~~
* Pascal Junod <[EMAIL PROTECTED]>  http://crypto.junod.info  *
* Security and Cryptography Laboratory (LASEC)   *
* Swiss Federal Institute of Technology (EPFL), CH-1015 Lausanne *
~~~

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