Saturday, November 29, 2008

Re: e-gold and e-go1d

On Nov 29, 2008, at 9:18 AM, James A. Donald wrote:
> The algorithm is to map all lookalike glyphs to
> canonical glyphs

The definition of lookalike glyphs depends on the choice of font and
variant, and Unicode wraps the whole problem in a lovely layer of
hell. If I had to do this, I'd investigate rendering both strings in
the (same) target font and then quantifying the amount of overlap in
the bitmaps, as e.g. SWORD does for TLDs:

<http://icann.sword-group.com/icann-algorithm/Default.aspx>

The above is proprietary; NIST's Paul Black has Python code available
for a slightly enhanced Levenshtein distance:

<http://hissa.nist.gov/~black/GTLD/>

--
Ivan Krstić <krstic@solarsail.hcs.harvard.edu> | http://radian.org

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

e-gold and e-go1d

To implement Zooko's triangle, one has to detect names
that may look alike, for example e-gold and e-go1d

This is a lot of code. Has someone already written such
a collision detector that I could swipe?

The algorithm is to map all lookalike glyphs to
canonical glyphs - thus l and 1 are mapped to l, O and 0
are mapped to O, lower case o and the Greek omicron are
mapped to lower case o, and so on and so forth. For
each pair of strings, one then does a character by
character diff, and pairs with suspiciously short diffs
might be confused by end users.

The program then asks the user for a qualification to
distinguish one or both of the names, default being as
first and second, or for the user to deprecate one of
the entities as scam or spam, or for the user to say he
does not care if new entries have the same or similar
name as this particular existing entry.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Friday, November 28, 2008

[FDE] OT: District Court Halts Sales of Keylogger Software

FTC v. CyberSpy Software:
http://jolt.law.harvard.edu/digest/software/ftc-v-cyberspy-software
_______________________________________________
FDE mailing list
FDE@www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde

CPRNGs are still an issue.

As it turns out, cryptographic pseudorandom number generators continue
to be a good place to look for security vulnerabilities -- see the
enclosed FreeBSD security advisory.

The more things change, the more they stay the same...

Perry

Begin forwarded message:

From: FreeBSD Security Advisories <security-advisories@freebsd.org>
To: FreeBSD Security Advisories <security-advisories@freebsd.org>
Subject: [FreeBSD-Announce] FreeBSD Security Advisory
FreeBSD-SA-08:11.arc4random

=============================================================================
FreeBSD-SA-08.11.arc4random Security Advisory
The FreeBSD Project

Topic: arc4random(9) predictable sequence vulnerability

Category: core
Module: sys
Announced: 2008-11-24
Credits: Robert Woolley, Mark Murray, Maxim Dounin, Ruslan Ermilov
Affects: All supported versions of FreeBSD.
Corrected: 2008-11-24 17:39:39 UTC (RELENG_7, 7.1-PRERELEASE)
2008-11-24 17:39:39 UTC (RELENG_7_0, 7.0-RELEASE-p6)
2008-11-24 17:39:39 UTC (RELENG_6, 6.4-STABLE)
2008-11-24 17:39:39 UTC (RELENG_6_4, 6.4-RELEASE)
2008-11-24 17:39:39 UTC (RELENG_6_3, 6.3-RELEASE-p6)
CVE Name: CVE-2008-5162

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:http://security.FreeBSD.org/>.

I. Background

arc4random(9) is a generic-purpose random number generator based on the
key stream generator of the RC4 cipher. It is expected to be
cryptographically strong, and used throughout the FreeBSD kernel for a
variety of purposes, some of which rely on its cryptographic strength.
arc4random(9) is periodically reseeded with entropy from the FreeBSD
kernel's Yarrow random number generator, which gathers entropy from a
variety of sources including hardware interrupts. During the boot
process, additional entropy is provided to the Yarrow random number
generator from userland, helping to ensure that adequate entropy is
present for cryptographic purposes.

II. Problem Description

When the arc4random(9) random number generator is initialized, there may
be inadequate entropy to meet the needs of kernel systems which rely on
arc4random(9); and it may take up to 5 minutes before arc4random(9) is
reseeded with secure entropy from the Yarrow random number generator.

III. Impact

All security-related kernel subsystems that rely on a quality random
number generator are subject to a wide range of possible attacks for the
300 seconds after boot or until 64k of random data is consumed. The list
includes:

* GEOM ELI providers with onetime keys. When a provider is configured in
a way so that it gets attached at the same time during boot (e.g. it
uses the rc subsystem to initialize) it might be possible for an
attacker to recover the encrypted data.

* GEOM shsec providers. The GEOM shsec subsytem is used to split a shared
secret between two providers so that it can be recovered when both of
them are present. This is done by writing the random sequence to one
of providers while appending the result of the random sequence on the
other host to the original data. If the provider was created within the
first 300 seconds after booting, it might be possible for an attacker
to extract the original data with access to only one of the two providers
between which the secret data is split.

* System processes started early after boot may receive predictable IDs.

* The 802.11 network stack uses arc4random(9) to generate initial vectors
(IV) for WEP encryption when operating in client mode and WEP
authentication challenges when operating in hostap mode, which may be
insecure.

* The IPv4, IPv6 and TCP/UDP protocol implementations rely on a quality
random number generator to produce unpredictable IP packet identifiers,
initial TCP sequence numbers and outgoing port numbers. During the
first 300 seconds after booting, it may be easier for an attacker to
execute IP session hijacking, OS fingerprinting, idle scanning, or in
some cases DNS cache poisoning and blind TCP data injection attacks.

* The kernel RPC code uses arc4random(9) to retrieve transaction
identifiers, which might make RPC clients vulnerable to hijacking
attacks.

IV. Workaround

No workaround is available for affected systems.

V. Solution

NOTE WELL: Any GEOM shsec providers which were created or written to
during the first 300 seconds after booting should be re-created after
applying this security update.

Perform one of the following:

1) Upgrade your vulnerable system to 6-STABLE, or 7-STABLE, or to the
RELENG_7_0, or RELENG_6_3 security branch dated after the correction
date.

2) To patch your present system:

The following patches have been verified to apply to FreeBSD 6.3 and
7.0 systems.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

[FreeBSD 7.x]
# fetch http://security.FreeBSD.org/patches/SA-08:11/arc4random.patch
# fetch http://security.FreeBSD.org/patches/SA-08:11/arc4random.patch.asc

[FreeBSD 6.x]
# fetch http://security.FreeBSD.org/patches/SA-08:11/arc4random6x.patch
# fetch http://security.FreeBSD.org/patches/SA-08:11/arc4random6x.patch.asc

b) Apply the patch.

# cd /usr/src
# patch < /path/to/patch

c) Recompile your kernel as described in
<URL:http://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
system.

VI. Correction details

The following list contains the revision numbers of each file that was
corrected in FreeBSD.

Branch Revision
Path
-------------------------------------------------------------------------
RELENG_6
src/sys/dev/random/randomdev.c 1.59.2.2
src/sys/dev/random/randomdev_soft.c 1.11.2.3
RELENG_6_4
src/UPDATING 1.416.2.40.2.2
src/sys/dev/random/randomdev.c 1.59.2.1.8.2
src/sys/dev/random/randomdev_soft.c 1.11.2.2.6.2
RELENG_6_3
src/UPDATING 1.416.2.37.2.11
src/sys/conf/newvers.sh 1.69.2.15.2.10
src/sys/dev/random/randomdev.c 1.59.2.1.6.1
src/sys/dev/random/randomdev_soft.c 1.11.2.2.4.1
RELENG_7
src/sys/dev/random/randomdev.c 1.61.2.1
src/sys/dev/random/randomdev_soft.c 1.15.2.1
RELENG_7_0
src/UPDATING 1.507.2.3.2.10
src/sys/conf/newvers.sh 1.72.2.5.2.10
src/sys/dev/random/randomdev.c 1.61.4.1
src/sys/dev/random/randomdev_soft.c 1.15.4.1
-------------------------------------------------------------------------

VII. References

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5162

The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-SA-08:11.arc4random.asc
_______________________________________________
freebsd-announce@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-announce
To unsubscribe, send any mail to "freebsd-announce-unsubscribe@freebsd.org"

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

old codes in life magazine archive

Photos of an old paper-and-pencil espionage cipher.

http://www.slugsite.com/archives/957

(Hat Tip: Bruce Schneier)

--
Perry E. Metzger perry@piermont.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Thursday, November 27, 2008

Re: Certificates turn 30, X.509 turns 20, no-one notices

On 11/27/08 05:13, Nicholas Bohm wrote:
> I've never been quite sure whether "Public" qualifies "Key" or
> "Infrastructure" - this may make a difference to what you count as a PKI.
>
> SWIFT (interbank messaging), BOLERO (bills of lading) and CREST (dealing
> in dematerialised stocks and shares) all use public key cryptography, I
> believe, and have all been reasonably successful; but they are all
> closed systems where each of the participants believes that it and the
> others can stand the risk of contractually-imposed non-repudiation rules
> (or they used to believe it, anyway).
>
> But what these examples illustrate, by the lack of "open" comparables,
> is the very limited utility of the technology.

in the past capitalization referred to CAs making the rounds of
wallstreet with $20B/annum business case (i.e. approx. $100/annum per
adult in the US).

The lower case "public key" met that an entity could make
their public key available ... as countermeasure to the shortcomings
of shared-secret (password/PIN) paradigm ... where a unique shared-secret
was required for every unique security domain (the current scenario where
scores or hundreds of unique shared-secrets have to be managed).

going from lower-case ... where an entity could share the same
public key with large number of different entities, to upper-case,
was the scenario justifying the $20B/annum business case.

sometimes the issue isn't whether the public key is open/closed ... the
issue is whether the business liability is between the parties
involved ... or should random, unrelated participants also get
involved in the business processes.

there have been some attempts at obfuscation ... attempting
to confuse the boundaries between the authentication technology
and the parties involved in business processes liability

i was at annual acm sigmod (aka database) conference in 91 (92?)
and during one of the sessions, somebody asked a question regarding
what was all this X.5xx stuff going on ... and the reply was that
a bunch of networking engineers were trying to re-invent 1960s
database technology.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: Certificates turn 30, X.509 turns 20, no-one notices

Peter Gutmann wrote:
> This doesn't seem to have garnered much attention, but this year marks two
> milestones in PKI: Loren Kohnfelder's thesis was published 30 years ago, and
> X.509v1 was published 20 years ago.
>
> As a sign of PKI's successful penetration of the marketplace, the premier get-
> together for PKI folks, the IDtrust Symposium (formerly the PKI Workshop and
> now in its eighth year) authenticates participants with... username and
> password, for lack of a working PKI.
>
> (OK, it's a bit of a cheap shot and it's been done before, but I thought it
> was especially significant this year :-).

I've never been quite sure whether "Public" qualifies "Key" or
"Infrastructure" - this may make a difference to what you count as a PKI.

SWIFT (interbank messaging), BOLERO (bills of lading) and CREST (dealing
in dematerialised stocks and shares) all use public key cryptography, I
believe, and have all been reasonably successful; but they are all
closed systems where each of the participants believes that it and the
others can stand the risk of contractually-imposed non-repudiation rules
(or they used to believe it, anyway).

But what these examples illustrate, by the lack of "open" comparables,
is the very limited utility of the technology.

Nicholas Bohm
--
Salkyns, Great Canfield, Takeley,
Bishop's Stortford CM22 6SX, UK

Phone 01279 870285 (+44 1279 870285)
Mobile 07715 419728 (+44 7715 419728)

PGP public key ID: 0x899DD7FF. Fingerprint:
5248 1320 B42E 84FC 1E8B A9E6 0912 AE66 899D D7FF

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Wednesday, November 26, 2008

HavenCo and Sealand

Slightly off-topic, but a cause celebre on cypherpunks some years ago
-- but HavenCo, which ran a datacenter on the "nation" of Sealand, is
no longer operating there:
http://www.theregister.co.uk/2008/11/25/havenco/ (pointer via Spaf's
blog).


--Steve Bellovin, http://www.cs.columbia.edu/~smb

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Tuesday, November 25, 2008

Re: Certificates turn 30, X.509 turns 20, no-one notices

On Nov 24, 2008, at 8:54 PM, Peter Gutmann wrote:

> This doesn't seem to have garnered much attention, but this year
> marks two
> milestones in PKI: Loren Kohnfelder's thesis was published 30 years
> ago, and
> X.509v1 was published 20 years ago.
>
> As a sign of PKI's successful penetration of the marketplace, the
> premier get-
> together for PKI folks, the IDtrust Symposium (formerly the PKI
> Workshop and
> now in its eighth year) authenticates participants with... username
> and
> password, for lack of a working PKI.
>
> (OK, it's a bit of a cheap shot and it's been done before, but I
> thought it
> was especially significant this year :-).

Yeah, they should be using OpenID. :-)

Jon


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Monday, November 24, 2008

Certificates turn 30, X.509 turns 20, no-one notices

This doesn't seem to have garnered much attention, but this year marks two
milestones in PKI: Loren Kohnfelder's thesis was published 30 years ago, and
X.509v1 was published 20 years ago.

As a sign of PKI's successful penetration of the marketplace, the premier get-
together for PKI folks, the IDtrust Symposium (formerly the PKI Workshop and
now in its eighth year) authenticates participants with... username and
password, for lack of a working PKI.

(OK, it's a bit of a cheap shot and it's been done before, but I thought it
was especially significant this year :-).

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Re: [FDE] MacBooks & FDE

 

WinMagic's SecureDoc for Mac supports hardware based encryption using Seagate's FDE drive on the Mac. For more information please check http://www.winmagic.com/apple/.

 

 

Garry McCracken

WinMagic


From: fde-bounces@www.xml-dev.com [mailto:fde-bounces@www.xml-dev.com] On Behalf Of Timothy Johnson
Sent: Sunday, November 16, 2008 6:21 PM
To: fde@www.xml-dev.com
Subject: [FDE] MacBooks & FDE

 

A question was asked over on StorageEffect.com if the FDE drive (aka SED for Self Encrypting Drive) can be installed into a MacBook Pro.  Does anyone know the answer?

 

http://tinyurl.com/56lv48

What are the system requirements for these drives? Can I slap one into my MacBook Pro? Or is it BIOS and Windows only? Or perhaps it needs a special BIOS

 

Saturday, November 22, 2008

Re: Raw RSA binary string and public key 'detection'

* Dirk-Willem van Gulik:

> Been looking at the Telnic (dev.telnic.org) effort.
>
> In essence; NAPTR dns records which contain private details such as a
> phone number. These are encrypted against the public keys of your
> friends (so if you have 20 friends and 3 phone numbers visible to all
> friends - you need 20 subdomains x 3 NAPTR entries under your
> master').
>
> Aside from the practicality of this - given a raw RSA encrypted block
> and a list of public keys - is there any risk that someone could
> establish which of those public keys may have been used to create that
> block ?

If the padding scheme is decent, this should not be possible without
breaking RSA.

However, the proposal limits keys to about 250*6 bits, which seems
rather restrictive for RSA keys.

I'm also concerned about reflective attacks were you ask someone who's
trusted by the data owner to decrypt the data for you, possibly in an
automated fashion.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com