Re: OpenID/Debian PRNG/DNS Cache poisoning advisory

2008-08-09 Thread Ben Laurie

Hal Finney wrote:

I thought of one possible mitigation that can protect OpenID end users
against remote web sites which have not patched their DNS. OpenID
providers who used weak OpenSSL certs would have to change their URLs
so that their old X.509 CA certs on their old URLs no longer work on the
new ones. This will require all of their clients (users who log in with
their OpenID credentials) to change their identifiers. DNS based MITMs
will not be able to forge messages related to the new identifiers.


Yeah, I considered this scheme. The problem is that it doesn't really 
help the relying parties, who can still be fooled into believing an 
existing user is returning (or a new one is arriving) from the original 
site. This is particularly a problem for Sun's OpenID Provider, which 
makes the additional assertion (out of band) that the user is a Sun 
employee. So, anyone can become a Sun employee, as of a few days ago.


This is why the lack of CRL checking in OpenID libraries is an issue.


Again, I see fixing the DNS as the path of least resistance here,
especially so since the end user is the one bearing most of the risk,
typically DNS is provided by an ISP or some other agency with a formal
legal relationship, and there is the possibility of liability on the
part of the lax DNS provider. Hopefully we will continue to see rapid
uptake of the DNS fix over the next few weeks.


In general, DNS is not fixable without deploying DNSSEC.

a) The current fix just reduces the probability of an attack. If 
attacker and victim have sufficient bandwidth, it can still be done in 
under a day.


b) There are many scenarios, mostly revolving around the use of wireless 
hotspots, where users are easily fooled into using a malicious DNS provider.


So, DNS patching is not, IMO, the real answer to this problem. Of 
course, the second scenario has been around forever, but is conveniently 
ignored when explaining why CRLs are not necessary (and all other things 
that rely on perfect DNS). All that's happened recently is we've made 
people who are sitting still just as vulnerable as travellers.


But increasingly we are all travellers some of the time, from a how we 
get our 'net POV. We really can't ignore this use case.


Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.links.org/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

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


Re: On the unpredictability of DNS

2008-08-09 Thread William Allen Simpson

It seems like enough time has passed to post publicly, as some of these
are now common knowledge:

Ben Laurie wrote:

William Allen Simpson wrote:

Keep in mind that the likely unpredictability is about 2**24.  In many
or most cases, that will be implementation limited to 2**18 or less.


Why?


Remember, this is the sum of the range of the 16-bit DNS header identifier
and the 16-bit UDP port number.

The theoretical maximum is less than 2**(16+16), as the ports less than
4096 are reserved.

Many or most implementations use only a pool of ports: 2**[9, 10, 12]
have been reported.

Some implementations (incorrectly) use positive signed integers for the
DNS identifier: 2**15.

And in this week's Hall of Shame, MacOSX Leopard patch for servers seems
to randomize the BIND request port in a small pool.  The next UDP packet
ports are sequential, so the range to guess is very small, simply by
looking at the following UDP packets.  Very strange reports coming out!
MacOSX total: about 2**18.

Worse, Apple didn't fix Leopard clients, didn't patch the stub resolver
library (neither did BIND), didn't patch earlier versions such as Panther.
Many, many MacOS systems are still vulnerable.

And in case you don't think this matters, once upon a time I helped build
an ISP entirely with Macs, resistant to most compromises.  There are far
more Macs used as resolvers than any other flavor of *nix.


I don't see why. A perfectly reasonable threat is that the attacker 
reverse engineers the PRNG (or just checks out the source). It doesn't 
need to be common to be predictable.



I don't understand this comment.

When MD5 is used as a PRNG, in this case the upper 32-bits of its 128-bit
output cycle, what amount of samples will reveal the seed, or the current
internal state of the sequence?

When ARC4 is used as PRNG, what amount of samples will reveal the seed or
the current state?

Are you only referring to reverse engineering trivially poor PRNG?

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


another proprietary symmetric cipher ?

2008-08-09 Thread dan

yet another proprietary symmetric cipher ?

http://www.pureentropy.com

...

Encryption Security Solutions provides unprecedented encryption
security, efficiency, and performance for business applications ensuring
critical information is secure.

Encryption Security Solutions, LLC (ES²) has developed an
innovative, proprietary symmetrical encryption algorithm (JUMBLE) for
commercial applications. This algorithm provides an end-to-end or site
solution, for use by individuals or across an enterprise environment.

Using the newly developed and proprietary JUMBLE encryption engine
allows ES² to provide multiple encryption solutions for all
digital data formats, including real-time streaming high definition
digital video. The JUMBLE engine can be integrated directly in the
client, at the web server, application server, or database layer. This
unique software solution goes beyond current platforms that contain such
things as centralized cryptographic processing, key management, policy
management, and security administration because it does not rely on
human procedure-based security practices. JUMBLE provides unprecedented
advantages in security, scalability and manageability.

...

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


Judge approves TRO to stop DEFCON presentation

2008-08-09 Thread Perry E. Metzger

It seems that US judges aren't as protective of speech rights as Dutch
ones.

Las Vegas - Three students at the Massachusetts Institute of
Technology (MIT) were ordered this morning by a federal court
judge to cancel their scheduled presentation about vulnerabilities
in Boston's transit fare payment system, violating their First
Amendment right to discuss their important research.

The Electronic Frontier Foundation (EFF) represents Zack Anderson,
RJ Ryan and Alessandro Chiesa, who were set to present their
findings Sunday at DEFCON, a security conference held in Las
Vegas. However, the Massachusetts Bay Transit Authority (MBTA)
sued the students and MIT in United States District Court in
Massachusetts on Friday, claiming that the students violated the
Computer Fraud and Abuse Act (CFAA) by delivering information to
conference attendees that could be used to defraud the MBTA of
transit fares. This morning District Judge Douglas P. Woodlock,
meeting in a special Saturday session, ordered the trio not to
disclose for ten days any information that could be used by others
to get free subway rides.

http://www.eff.org/press/archives/2008/08/09

-- 
Perry E. Metzger[EMAIL PROTECTED]

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


Re: Judge approves TRO to stop DEFCON presentation

2008-08-09 Thread Ivan Krstić
On Sat, 09 Aug 2008 17:11:11 -0400, Perry E. Metzger [EMAIL PROTECTED]
wrote:
 Las Vegas - Three students at the Massachusetts Institute of
 Technology (MIT) were ordered this morning by a federal court
 judge to cancel their scheduled presentation about vulnerabilities
 in Boston's transit fare payment system, violating their First
 Amendment right to discuss their important research.

http://www-tech.mit.edu/V128/N30/subway/Defcon_Presentation.pdf

-- 
Ivan Krsti? [EMAIL PROTECTED] | http://radian.org

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


Re: Judge approves TRO to stop DEFCON presentation

2008-08-09 Thread Jim Youll
these have been circulating for hours, but they are content-free title  
slides...


[Moderator's note: I've read them and they're far from content
free. They give you a recipe for doing things like rewriting the mag
stripes on stored value cards to give you arbitrary balances, and
they even include actual examples. Also, Please Don't Top
Post. Please cut down quoted material to just the important content,
too. -Perry]

On Aug 9, 2008, at 7:38 PM, Ivan Krstić wrote:

On Sat, 09 Aug 2008 17:11:11 -0400, Perry E. Metzger [EMAIL PROTECTED] 


wrote:

   Las Vegas - Three students at the Massachusetts Institute of
   Technology (MIT) were ordered this morning by a federal court
   judge to cancel their scheduled presentation about vulnerabilities
   in Boston's transit fare payment system, violating their First
   Amendment right to discuss their important research.


http://www-tech.mit.edu/V128/N30/subway/Defcon_Presentation.pdf

--
Ivan Krsti? [EMAIL PROTECTED] | http://radian.org

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


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