Re: Quiet in the list...

2008-09-06 Thread Sidney Markowitz

IanG wrote, On 7/9/08 2:06 AM:
Then, when a new Thunderbird comes out, you load that up and 
the other packages cease to work


As far as I recall, the last time Thunderbird had an upgrade it told me 
that one was available, I clicked to upgrade, and the addons, including 
Enigmail, continue to work. When there was an upgrade available to 
Enigmail, same thing. And the upgrade to GNUgpg also installed cleanly 
with no reconfiguration necessary. It has all been as transparent as can be.


My only problem with it is that I keep having this nagging feeling in 
the back of my mind that set it and forget it is not the best approach 
to security.


 -- sidney

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


Re: Kaminsky finds DNS exploit

2008-07-10 Thread Sidney Markowitz

Udhay Shankar N wrote, On 9/7/08 5:52 PM:
I think Dan Kaminsky is on this list. Any other tidbits you can add 
prior to Black Hat?


He's posted a quite long article on his blog

 http://www.doxpara.com/?p=1162

that looks like all the details he is likely to provide for the next 30 
days. It does seem to address the speculation on this list about how the 
patch relates to stuff that has been known for years, Dan Bernstein's 
code, who knew what when, etc.



  -- sidney

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


Re: SSL/TLS and port 587

2008-01-23 Thread Sidney Markowitz

Ed Gerck wrote, On 23/1/08 7:38 AM:

The often expressed idea that SSL/TLS and port 587 are somehow able to prevent
warrantless wiretapping and so on, or protect any private communications, is 
IMO simply
not supported by facts.


I would like to see some facts to support the assertion that the idea that SSL/TLS and 
port 587 are somehow able to prevent warrantless wiretapping is often expressed.


A Google search for
 ssl port 587 warrantless wiretapping
got exactly one hit, which was your posting to the mailing list where it had been archived 
on security-basic.blogspot.com and snarfed up by Google within the hour.


(As an aside, see Google Taking Blog Comments Searching Real-Time? 
http://www.groklaw.net/article.php?story=20080122132516514 for a discussion of this 
remarkable update to their search engine).


 Sidney Markowitz
 http://www.sidney.com/

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


Re: Question on export issues

2008-01-07 Thread Sidney Markowitz

Ivan Krsti? wrote, On 6/1/08 1:33 PM:

On Jan 3, 2008, at 10:47 PM, Peter Gutmann wrote:

That's because there's nothing much to publish:
In the US, notify the BIS via email.


Our outside counsel -- specializing in this area -- thought this was  
insufficient


That's the problem with using lawyers, they'll always give you a conservative cautious 
answer. Unfortunately for people who don't use them, sometimes those really are the 
correct, prudent answers. When I worked for a company that had to face this we acted 
according to what looked like the plain language documentation from the BIS, concluding 
that use of an existing open source package required just sending an email. We were never 
as high profile as OLPC and in fact never ended up exporting anything, so our 
interpretation of the laws was not only not made by qualified legal counsel, it also was 
never tested.


I do look forwrd to seeing what you discover were the considerations that your outide 
counsel had.


 -- sidney

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


Re: Question on export issues

2007-12-31 Thread Sidney Markowitz
Ivan Krsti? wrote, On 31/12/07 12:48 PM:
 We've recently had to jump through the BIS crypto export hoops at  
 OLPC

I find that very strange considering this from a BIS FAQ
http://www.bis.doc.gov/encryption/encfaqs6_17_02.html

all encryption source code that would be considered publicly available under 
Section
734.3(b)(3) of the EAR (such as source code posted to the Internet) and the 
corresponding
object code may be exported and reexported under License Exception TSU -- 
Technology and
Software Unrestricted (specifically, Section 740.13(e) of the EAR), once 
notification (or
a copy of the source code) is provided to BIS and the ENC Encryption Request 
Coordinator.

What hoops did you have to jump through?

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


Re: Scare tactic?

2007-09-21 Thread Sidney Markowitz
Sidney Markowitz wrote, On 21/9/07 8:24 AM:
 Ben Laurie wrote, On 21/9/07 1:34 AM:
 Entity i cannot be coerced into sharing a key with entity j without i’s
 knowledge, ie, when i believes the key is shared with some entity l != j.
 
 The without i's knowledge part is critical to the argument, as the
 author is assuming that entity i is monitoring all of entity j's
 channels of communication

Curse this non-standard notation! I of course meant entity l
everywhere I said entity j to keep with the original author's
nomenclature. Whatever happened to Alice, Bob, and Eve?

 -- Sidney Markowitz
http://www.sidney.com


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


Re: Scare tactic?

2007-09-20 Thread Sidney Markowitz
Ben Laurie wrote, On 21/9/07 1:34 AM:
 It seems to me that the requirement cited:
 
 Entity i cannot be coerced into sharing a key with entity j without i’s
 knowledge, ie, when i believes the key is shared with some entity l != j.

The without i's knowledge part is critical to the argument, as the
author is assuming that entity i is monitoring all of entity j's
channels of communication and either entity j has no communication of
any kind outside of that used for the DH protocol with entity i, or else
entity i would be able to recognize whether any other communication with
anyone is a revelation of the secret session key that entity i is
sharing with entity j.

Note that entity i would even have to be sure that entity j is not using
any side channels such as variations in the timing of response packets
during the subsequent encrypted session to communicate with a colluding
passive attacker who is eavesdropping.

That is an awfully impractical constraint on the threat model, which
makes this issue moot in practice.

 Sidney Markowitz
 http://www.sidney.com

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


Latest AACS key cracked a week before release

2007-05-18 Thread Sidney Markowitz
Ars Technica reports that a new volume key which has been issued to
replace the one that was cracked earlier this month and which is being
used in DVDs to be released for sale next week has been cracked using a
beta version of SlySoft's AnyDVD HD program and early release previews
of The Matrix trilogy.

Here's the article

http://arstechnica.com/news.ars/post/20070517-latest-aacs-revision-defeated-a-week-before-release.html

This is the same link in preview tinyurl form:

http://preview.tinyurl.com/2zl4gv


I know that there is nothing technologically new or interesting about
this crack, but it does add a certain emphasis to the arguments for the
futility of DRM, seeing systems cracked before they are released. What
does it do to Ed Felten's model when C drops below 0? (reference Hal
Finney's post to this list about two weeks ago
http://article.gmane.org/gmane.comp.encryption.general/10065)

 -- Sidney Markowitz
http://www.sidney.com

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


Yet a deeper crack in the AACS

2007-05-04 Thread Sidney Markowitz
Article AACS cracks cannot be revoked, says hacker

http://arstechnica.com/news.ars/post/20070415-aacs-cracks-cannot-be-revoked-says-hacker.html

Excerpt: The latest attack vector bypasses the encryption performed
by the Device Keys -- the same keys that were revoked by the WinDVD
update -- and the so-called 'Host Private Key,' which as yet has not
been found. This was accomplished by de-soldering the HD DVD drive's
firmware chip, reading its contents, and then patching it. Once that
was done, the firmware was soldered back onto the drive.

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


Re: 128 bit number T-shirt?

2007-05-02 Thread Sidney Markowitz
Ivan Krstić wrote, On 3/5/07 4:50 AM:
 But all the artwork is just ugly numbers in a monospace font

My thoughts too. This one looks much better, but I don't see a link
anywhere to get it. Perhaps the author just photoshopped the picture as
a proof of concept to go with his blog comment?

http://www.ghacks.net/2007/04/30/09-f9-11-02-t-shirt

 -- sidney

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


Re: Cryptome cut off by NTT/Verio

2007-04-29 Thread Sidney Markowitz
Cryptome.org has not been shut down yet (the notice from Verio dated 28
April says they were being given two weeks to find another provider).
They seem to have been slashdotted.

The shutdown notice page is not yet archivd at archive.org, but is
mirrored on a responsive site, mirror.org:

http://www.mirrordot.org/stories/e231a81023b07bf399b68b2c295e9736/

Here's a comment by John Young in the slashdot thread:
http://slashdot.org/comments.pl?sid=232691cid=18919481

It links to a page on cryptome.org, which of course is unavailable
during the slashdotting but is in the archive.org archives:

http://web.archive.org/web/*/http://cryptome.org/stoa-atpc.htm

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


Re: AES128-CBC Question

2007-04-19 Thread Sidney Markowitz
Aram Perez wrote, On 19/4/07 6:29 PM:
 Is there any danger in using AES128-CBC with a fixed IV of all zeros?

Here is some discussion about doing this, in the context of PGP doing
just that and why PGP inserts random characters at the begining of the
plaintext.

 http://archive.cert.uni-stuttgart.de/openpgp/2003/04/msg00026.html

It points out that a fixed IV results in information leakage if the
first block or more of plaintext is the same in two messages encrypted
with the same key.

 Sidney Markowitz
 http://www.sidney.com

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


Re: general defensive crypto coding principles

2006-02-08 Thread Sidney Markowitz
Simon Josefsson wrote:
 Travis H. [EMAIL PROTECTED] writes:
 ...
 3) Authenticate the plaintext, not the ciphertext.  This is a general
[...]
 I wonder whether this is really a good suggestion, considering
 Krawczyk's paper that show that this construct is not generically
 secure.  See http://eprint.iacr.org/2001/045.

Schneier deals with that explicitly when he makes the suggestion, on pp 115-117
in Practical Cryptography, referring to theoretical results rather than
referencing Krawczyk's paper directly.

Krawczyk's paper shows that authenticate before encryption is not secure under
assumptions that are not realistic, such as the encryption being subject to a
chosen ciphertext attack, use of ECB mode, separate MAC authentication of each
block along with an encryption oracle so you can use a kind of block level
replay attack in CBC mode. If you use a good cipher with an appropriate mode
and apply the authentication to the entire message with proper use of message
ID or timestamp to prevent replay attacks, you avoid Krawczyk's vulnerabilities
four times over.

Schneier deals with the argument about potential DoS attacks by pointing out
that most real-life DoS attacks saturate the communication channel, not the CPU.

He also presents arguments for authenticating before encrypting which I won't
repeat here -- It's all there in a pretty clear three pages in his book.

 -- Sidney Markowitz
http://www.sidney.com

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


Re: serious threat models

2006-02-04 Thread Sidney Markowitz
Matt Blaze wrote:
 Yes, it's not at all clear from these stories just what was
 going on or how high tech the attack would have to be. What does
 diverting to a prepaid mobile mean?

There is more information in Bruce Scheier's blog entry and his links to blog
and news articles. It hit slashdot yesterday:

http://www.schneier.com/blog/archives/2006/02/phone_tapping_i.html

According to those reports, the attack involved modifying (configuring?)
software on a Vodafone switch to cause all calls to/from some 100 mobile phone
numbers to be conference calls with some prepaid mobile numbers that recorded
the conversations.

 Sidney Markowitz
 http://www.sidney.com

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


Re: RNG quality verification

2006-01-03 Thread Sidney Markowitz
Philipp Gühring wrote:
 I took OpenSSL, generated 1 RSA keys, and took them apart.
 First I analyzed the raw keys:

Try this:

Generate 256000 bytes from MD5(i), i=1...16000 and run the same tests. That is
clearly not acceptable as a PRNG because it is completely predictable if you
know that the sequence is MD5(1) ... MD5(16000), but it should pass any tests
other than one that checks specifically if it is correlated to MD5(1) ...
MD5(16000).

Perhaps you would say that example is unfair because MD5 makes a perfectly good
PRNG as long as the software package seeds it properly. In that case, how are
you going to ensure that the package you are testing is seeding the PRNG 
properly?

In fact, the famous Netscape vulnerability was based on a PRNG that was simply
MD5 of a counter, with the vulnerability being predictability of the seed. See
http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html for a clear
description of that.

Your tests would not detect that kind of vulnerability.

You asked,
 Has anyone tested yet, how much samples are needed to detect those PRNGs?

The point is that your tests will not detect the difference between a PRNG
using a properly seeded MD5(counter) and one with a predictable seed. More
generally, a sequence can be predictable while still being statistically random.

Carrying it even further, back in 1996 the only problem with using MD5 of a
counter as a PRNG was making sure that the seed was unpredictable. That may not
be true anymore because of recent results of MD5 collisions, or more
accurately, it may not remain true if stronger attacks continue to be found.
Statistical tests have not all of a sudden changed their results: MD5 will not
appear any less random in those tests just because vulnerabilities are found.

So how do you certify PRNGs used by your customers? You have them use well
known software packages that have been analyzed and vetted by the cryptographic
community, such as OpenSSL. It would be a shock if any of them did not pass the
simple statistical tests that you can perform. Passing those tests does not
ensure that there are none of the more subtle vulnerabilities that are only
discovered by many smart people taking a very hard look over a significant time
period.

 -- Sidney Markowitz
http://www.sidney.com

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


Re: browser vendors and CAs agreeing on high-assurance certificat es

2005-12-18 Thread Sidney Markowitz
On 12/19/05 9:54 AM, [EMAIL PROTECTED] wrote:
 Imagine a E-commerce front end:  Instead of little-guy.com buying a cert
 which you are supposed to trust, they go to e-commerce.com and pay for a
 link.  Everyone trusts e-commerce.com and its cert.  e-commerce provides a
 guarantee of some sort to customers who go through it, and charges the
 little guys for the right.

Do you mean like Amazon Marketplace and Amazon zShops? I think it's been
done already:

http://www.amazon.com/exec/obidos/tg/browse/-/1161232/103-4791981-1614232

 -- Sidney Markowitz
http://www.sidney.com

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


Re: Fermat's primality test vs. Miller-Rabin

2005-12-06 Thread Sidney Markowitz
Joseph Ashwood wrote:
 Apparently, they are, I'm ran a sample, but even with the added second 
 sanity check, every one of them that passes a single round comes up prime.
 
 I then proceeded to move it to 2048-bit numbers. It takes longer and the 
 gaps between primes is averaging around 700 right now, but once again if it 
 passes a single test it passes all 128+128

Ok, I did misunderstand you. If that failed 120-130 times is talking about
the number of trials between primes, then you are getting within the range of
expected results.

According to the prime number theorem, the probability of selecting a prime
number at random from odd numbers is about 2/ln(n) which for a 512 bit number
is about 1 in 177, which means you have about a 50% chance of 120 tries before
finding a prime.

According to the results that Anton quoted there is a 2^56 chance that a 512
bit odd number that passes one round of Miller-Rabin is actually prime.

So all of your results do make sense.

 -- sidney

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


Re: Fermat's primality test vs. Miller-Rabin

2005-12-05 Thread Sidney Markowitz
Joseph Ashwood wrote:
 Granted this is only a test of the 
 generation of 128 numbers, but I got 128 primes (based on 128 MR rounds). 

That doesn't make sense, unless I'm misinterpreting what you are saying. Primes
aren't that common, are they?

I don't have time right now to look for a bug in your code, but you could add a
sanity check that would catch a bug immediately by adding in the appropriate
spot a test like

 if (!curnum.isProbablePrime(128))
   System.out.println(Something wrong, number is not really a prime!);


to check that your primality test gets the same result as the M-R primality
test that comes with BigInteger.

 -- sidney

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


Re: Fermat's primality test vs. Miller-Rabin

2005-12-03 Thread Sidney Markowitz
Joseph Ashwood wrote:
   byte [] rawBytes = new byte[lenNum/8];
   rand.nextBytes(rawBytes);
   curNum = new BigInteger(rawBytes);

I haven't thought through why it would produce non-primes, but it
doesn't seem to do what you want. That produces a 512 bit
twos-complement number, which gives you a 511 bit positive integer, not
512 bit. It also is unnecessarily complicated compared to this form of
the BigInteger constructor and the or method (see the javadoc):

curNum = BigInteger.ONE.or(new BigInteger(512, rand));

 -- Sidney Markowitz
http://www.sidney.com

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


Re: NSA Suite B Cryptography

2005-10-15 Thread Sidney Markowitz
Joseph Ashwood wrote:
 U, no. The NSA only licensed the right to use (and sublicense under 
 special circumstances) the patents
[...]
 [snip the rest, it was based on a failed assumption]

Poor phrasing on my part. Exactly as you said, the patent sublicense
cannot be passed on even if the code is released under, say a BSD
copyright license. People would have a right to copy the source code but
would have to obtain patent rights either from the NSA if they are
eligible, or as you said under alternative arrangements from Certicom.

Since the GPL excludes distribution of code with patents that limit
their distribution other than by specific country, the patent
encumbrance that would accompany the code would prevent it from being
released under GPL.

The possible twist that I see is if the NSA declares that any freely
available open source software that interoperates with Suite B is by
definition in support of US national security interests and therefore
automatically gets one of their sublicenses. That would effectively
remove the patent encumbrance for GPL code. There would still be patent
restrictions on the code, but they would not apply to open source freely
redistributable code, therefore would not get in the way of the GPL.

Oh, no, that would not be strictly true. GPL allows you to do anything
at all with the code if you use it for yourself without distributing it.
Patent restrictions still apply to such uses. They could be uses that
are not in support of US national security interests. Therefore you
still could not distribute the code under GPL as the people you give it
to would not have the patent rights to modify the code for their own
private modified use if they do not distribute the changes.

So it still comes down to what I think is the important point: BSD
licensed Suite B code may be possible, GPL'd Suite B code is not
possible unless Certicom makes appropriate free license to the patents
available for software licensed under GPL.

 -- Sidney Markowitz
http://www.sidney.com



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


Re: NSA Suite B Cryptography

2005-10-14 Thread Sidney Markowitz
Excerpt from
 Fact Sheet on NSA Suite B Cryptography
 http://www.nsa.gov/ia/industry/crypto_suite_b.cfm

NSA has determined that beyond the 1024-bit public key cryptography in
common use today, rather than increase key sizes beyond 1024-bits, a
switch to elliptic curve technology is warranted. In order to facilitate
adoption of Suite B by industry, NSA has licensed the rights to 26
patents held by Certicom Inc. covering a variety of elliptic curve
technology. Under the license, NSA has a right to sublicense vendors
building equipment or components in support of US national security
interests.

Does this prevent free software interoperability with Suite B standards?
It potentially could be used to block non-US vendors, certainly anyone
who is in the US Government's disfavor, but it seems to me that even
with no further intentional action by the NSA it would preclude software
under the GPL and maybe FOSS in general in countries in which the
patents are valid.

 -- Sidney Markowitz
http://www.sidney.com

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


Re: NSA Suite B Cryptography

2005-10-14 Thread Sidney Markowitz
Ian G wrote:
 Which is to say, NSA solved its problem and it
 is nothing to do with FOSS.

If you wrote a Suite B program and distributed it under a BSD license
after getting a sub-license for the patent from the NSA, presumably I
could take that code, modify it, and then in order to use or distribute
 my modified code I would have to obtain my own sublicense from the NSA.

I could do that as long as I met whatever criteria the NSA has for
granting sublicenses. My guess is that at a minimum the program would
have to be available for free or for sale to the US government for some
purpose that allows it to be considered as being in support of US
national security interests.

It would make no sense for the NSA to grant a sublicense to you that
allowed to you grant me a license to produce possibly proprietary code
that infringes the patent and is not in support of US national security
interests.

So, yes, under those assumptions BSD-like licenses would not be
excluded, with the understanding that in addition to the copyright terms
allowing free use of the code there would also be patent restrictions
affecting the use.

As you say, the NSA's solution to their problem has nothing to do with
FOSS, and it doesn't specifically exclude FOSS. But it will preclude GPL
software that will interoperate with Suite B from being distributed in
countries that recognize the patents.

Unless, I suppose the NSA is able to say that any use of the patent in
open source software can be considered in support of US national
security interests and therefore the sublicense can be propagated as
long as the source remains available. In other words, if they include a
GPL-like provision that the patent license will stay with the code as
long as it is distributed under GPL. That would be an interesting twist.

 -- Sidney Markowitz
http://www.sidney.com

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


Re: US Banks: Training the next generation of phishing victims

2005-10-12 Thread Sidney Markowitz
Peter Gutmann wrote:
 (hmm, their admins must have gone to the same security night school as the BoA
 ones :-).

I don't understand how big companies can be willing to send their
customers through multilayer telephone menu hell just to be put on hold
for 20 minutes, but think that it is unacceptable to have to click a
Secure Online Banking button on the home page before entering their id
and password. As you have pointed out, the latter seems to be the
standard for banks outside the US, and I'm sure it works for them.

It looks like they are all getting their web sites from the same
Hack-In-A-Box. I just checked out my credit union in the US that used to
be an example of doing things right so I could say something nice about
them here, but it appears that their online management have also been
replaced by the same pod people since I last had a reason to do online
transactions with them.

When I entered the http://www.bayfed.org URL that I'm familiar with, the
first thing that happened was an immediate and invisible redirect to
http://www.bayfed.com. Ok, maybe they finally bought that domain and
decided to standardize on it. The behavior I remember it having a couple
of years ago was an immediate redirect to https://www.bayfed.org.

There on the home page is a form to enter my member number and password
and a login button. Next to it is a turquoise padlock icon labeled
security advisory. The word advisory led to me to think, Aha,
they've succumbed to the dark side under management pressure, but at
least they are going to warn me that this is not really secure and if I
want to prevent any phishing attack I should do something like click on
the login button without entering my information, then actually enter on
the secured site.

Nope. Hovering the mouse over the icon tells me that they secure their
transactions using 128-bit SSL and I can get more information by
clicking on the icon. Clicking it brings up a page saying... Yes, the
same pod people wrote their web site:

Online Security Policy

You may notice when you are on our public web site that some familiar
indicators do not appear in your browser to confirm the entire page is
secure. These indicators include the small padlock icon in your
browser's status area and the https prefix in the Address bar. To
provide all of our users with the fastest and most responsive possible
access to our web site, we have chosen to make the process of signing in
to Online Banking secure without unnecessarily securing any additional
pages on the public web site. Again, please be assured that your member
number, password and other information are secure, and that Bay Federal
alone has access to them: only public, non-sensitive web pages will
remain unsecured, while any page that collects or reveals your sensitive
personal information will continue to be handled with the strictest
available security measures.

Hmm, one difference from the BoA and Wachovia examples is that this is
under the heading Security Policy. It can be argued that their
unsecured home page, which collects a member number and password,
violates the portion of the policy that says only public, non-sensitive
web pages will remain unsecured, while any page that collects or reveals
your sensitive personal information will continue to be handled with the
strictest available security measures.

By the way, it does get worse. https://www.bayfed.org gives me a warning
about a certificate that expired over a year ago, then when I accept it
redirects me to the unsecured http://www.bayfed.com. Clicking on the
login button on the home page without entering my ID and password does
not take me to a secured page that gives me a chance to log in securely
-- Just a page that says that the ID and/or password are not valid, with
no exit other than the browser back button. So there appears to be no
way to get to an SSL secured login page even if I wanted to. Well, there
is a way. If I notice the URL of the invalid user error page I can guess
that https://ebanking.bayfed.com/ might work, and indeed it does present
a login page. Thanks, BayFed.

 -- Sidney Markowitz
http://www.sidney.com

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


Re: European country forbids its citizens from smiling for passport photos

2005-09-17 Thread Sidney Markowitz
New Zealand did this earlier this year, as part of giving in to pressure 
from the US to have passports with biometric information.


Here is a press release of last June from the NZ Green Party's Human 
Rights spokesperson. A quote from it Most people arriving in our fair 
land have smiles on their faces and there is nothing wrong with having 
passport photos to match


http://www.greens.org.nz/searchdocs/PR8903.html

 -- Sidney Markowitz
http://www.sidney.com

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


Clearing sensitive in-memory data in perl

2005-09-11 Thread Sidney Markowitz
Does anyone know of an open source crypto package written in perl that 
is careful to try to clear sensitive data structures before they are 
released to the garbage collector?


Failing that, does anyone know of an example that tries to deal with the 
particularly bad effect that at least on some perl platforms writing to 
a tied DB_File results in data from garbage collected strings appearing 
in the unused space between the logical end of file and the end of the 
allocated disk block?


And failing that, how about a reference to how one would go about 
preventing leaking sensitive information in garbage collected strings 
when writing in perl. Google and reading perl documentation hasn't 
helped me so far, but I find it hard to believe that this has not been 
considered when writing crypto software in perl.


Thanks,

 Sidney Markowitz
 http://www.sidney.com

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


Re: AES implementation in C - any recommendations?

2005-09-03 Thread Sidney Markowitz
Ian G wrote:
 I'm after an AES implementation in C, preferably with
 something approximating BSD/open licence.  Does anyone
 have a view on which would be a current favourite?

Brian Gladman's code is the fastest free version I know of, is widely used,
and has a BSD-like license.

http://fp.gladman.plus.com/AES/

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


Re: Motorist wins case after maths whizzes break speed camera code

2005-08-12 Thread Sidney Markowitz
Looking at the article and the links that were posted here,

1. It appears that the defense won only because the prosecution did not come
up with an expert to refute the defense expert. He could have argued based
on Goedel's Theorem or the Heisenberg Uncertainty Principle and the case
would have gone the same way.

2. The NRMA has called for a full audit of the way the state's 110
enforcement cameras are used ... Note that NRMA is a motorist association,
like the AAA in the US. This is not a government body nor anyone with
authority calling for an audit.

3. The expert may not have outright lied by saying that the MD5 collision
result theoretically means that RTA could change the speed without
changing the hash, but his definition of theoretically has to include
leaving it in the realm of theory by not trying to think the problem
through. This is not a situation where you can throw some random looking
bits in to make the hash come out right. Actually reading the article again
I don't see it made explicit that the person quoted was the expert used by
the defense or if he is just someone the reporter went to for a comment on
the story. For all we know the defense lawyer made the claim that People
have shown it [MD5] has been hacked and it's open to viruses, and without a
prosecution rebuttal that was enough.

4. The marketing speak that Aram linked to is not all that bad for marketing
people making a hash of technical jargon they have been given. My assumption
is that they sign the time, date, place, numberplate and speed record using
RSA/MD5. Trying to explain that to a non-techie and they will hear the words
public key, encryption, and MD5 hash, so it is not unreasonable for them to
write public key authenticated using MD5 encryption to ensure information
is authentic and tamper free.

5. Back to point #3, the attack on MD5 doesn't seem to cast doubt on the
signed data from the speed camera, as long as one can trust that the private
key is safely hidden in the camera. As Aram pointed out it is easy to show
that no possible speed, time and date will hash with the same numberplate to
get the same value.

 -- Sidney Markowitz
http://www.sidney.com

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


Re: Digital Water Marks Thieves

2005-02-22 Thread Sidney Markowitz
Matt Crawford wrote:
 How do the tiny particles know that it's not a civilian
 illuminating them with ultraviolet light?
 
 And how does Wired reporter Robert Andrews fail to ask that question?

And other people complain about how someone can spray their paint on
someone else's valuable and then call the police.

These arguments remind me of Peter Gutmann's recent post to the list
about good enough security... You can make the same arguments about
the DNA signature in blood. A civilian can analyze it. It is conceivable
that someone can get a sample of someone else's blood or other
biological sample and frame them by leaving DNA evidence somewhere. That
does not make DNA analysis useless as a tool in forensics.

So now there is a way of marking items that cannot be engraved and a way
of marking intruders. It sounds more sophisticated than a red dye bomb
in a sack of cash stored in a bank vault -- which also has its uses and
its drawbacks. Now it will be easier to tie the dyed material and the
dyed thieves to the specific crime. It is not a big deal that it does
not solve all problems in one stroke.

 -- sidney markowitz
http://www.sidney.com

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


Re: The Pointlessness of the MD5 'attacks'

2004-12-22 Thread Sidney Markowitz
This isn't worked out enough to be a proof of concept, but I can imagine 
a piece of code that has a comment This can't overflow because value X 
computed from the magic bits table will always be between A and B. Get 
0.1% speed boost by leaving out range check here but don't change magic 
bits.

That doesn't even have to be so obscure. It provides a place to 
introduce a security hole that will not be noticed by substituting a new 
magic bits table without the protective property. Unless someone takes 
their copy of the source code that has MD5 equal to the MD5 of the 
sources that have been reviewed by the experts and verifies for 
themselves whether their magic bits table does compute a value X between 
A and B, they are vulnerable. If MD5 is trusted, there is no reason to 
audit every downloaded copy of the source code like that, as long as you 
are sure that someone has done the audit.

 -- sidney
http://www.sidney.com/
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: [OT] Encryption

2004-01-03 Thread Sidney Markowitz
[Moderator's note: that's one -- but only one -- of the reasons I
think Bob found the exchange so funny. --Perry]
Ah, I thought he was being honest but naive and couldn't understand how 
he could apply for clearance from the US for an import.

I looked at the rest of the thread in their mailing list archive and see 
where he has claimed to be able to crack any AES-128 encrypted document 
in 20 minutes and that he has references to the current scientific 
literature showing that such times are well known state of the art. He 
says he will demonstrate decrypting a document one of the list members 
sent him and post the literature references when he is back in his 
office during the week.

If I had read that first I would not have wondered about the US import 
restrictions :-)

 -- sidney

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


Re: yahoo to use public key technology for anti-spam

2003-12-09 Thread Sidney Markowitz
[EMAIL PROTECTED] wrote:
Does anybody know what has become of the low-tech,
no-cryptography-needed RMX DNS record entry proposal?
A google search for rmx dns without quotes brings up as its first hit 
the Internet Draft at IETF which is dated October 2003. The subsequent 
hits show lots of discussion about it.

You might also be interested in http://spf.pobox.com which seems to be a 
similar proposal that extends the MX record rather than define a new rmx 
record.

To bring it back to the cryptography topic of this list, the draft 
proposal for rmx brings up a problem with crypto solutions that I did 
not see mentioned here yet. I'll just quote the relevant paragraph from 
the Draft rather than summarize it. Note that the draft states that it 
specifies only non-cryptographic mechanisms but still allows use of 
cryptography.

[begin quote]
2.4.  Shortcomings of cryptographical approaches
 At a first glance, the problem of sender address forgery might
 appear to be solvable with cryptographic methods such as challenge
 response authentications or digital signatures. A deeper analysis
 shows that only a small, closed user group could be covered with
 cryptographical methods. Any method used to stop spam forgery must
 be suitable to detect forgery not only for a small number of
 particular addresses, but for all addresses on the world. An
 attacker does not need to know the secrets belonging to a
 particular address. It is sufficient to be able to forge any
 address and thus to know any secret key. Since there are several
 hundreds of millions of users, there will always be a large amount
 of compromised keys, thus spoiling any common cryptographic method.
 Furthermore, cryptography has proven to be far too complicated and
 error prone to be commonly administered and reliably implemented.
 Many e-mail and DNS administrators do not have the knowledge
 required to deal with cryptographic mechanisms. Many legislations
 do not allow the general deployment of cryptography and a directory
 service with public keys. For these reasons, cryptography is
 applicable only to a small and closed group of users, but not to
 all participants of the e-mail service.
[end quote]
 -- sidney

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


Re: yahoo to use public key technology for anti-spam

2003-12-07 Thread Sidney Markowitz
Carl Ellison wrote:
So, in capsule: this proposal assumes that you use
the same machine for outgoing and incoming e-mail.
No, it implies a service that your outgoing mail server makes available 
that has you authenticate to it in some way and then signs your mail in 
some way.

The article doesn't make clear exactly how it would work. The signature 
might just certify that the mail really was sent through the mail server 
that the headers claim was used. That would allow you to use any email 
address that you want, such as your acm.org address, and the signature 
certifies that you authenticated yourself with the SMTP server.

My ISP recently switched to using TLS SMTP/Auth for access to their SMTP 
server from outside their network for their customers. It would be easy 
and useful for them to stamp mail that I send to show that it really was 
sent through their SMTP server and that they know who I am.

This might not be exactly the same as what Yahoo! is talking about: They 
might be thinking only about mail with a yahoo.com From address being 
sent through a yahoo.com server and being signed with a key associated 
with the yahoo.com domain. But if the signature is taken to authenticate 
the domain of the SMTP server in the initial Received header, then it is 
possible to maintain lists of servers of ISPs who are trusted to 
authenticate users of their SMTP servers and to have anti-spam policies, 
and blacklists of servers that are spam sources. The From address would 
be irrelevant.

 -- sidney

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


Re: yahoo to use public key technology for anti-spam

2003-12-07 Thread Sidney Markowitz
[EMAIL PROTECTED] wrote:
To avoid replay attacks one needs to
sign a string that is tied to a
specific message or time period
I agree. Even time period and message content aren't good enough: Let's 
say that the outgoing SMTP mailer at example.com is trusted. Spammer 
gets an account at example.com, sends themselves one message, then 
immediately copies the signature into forged headers for their spam that 
is sent out through whatever open relays or compromised machines they 
are using. The only way that the mail can be trusted is if it is being 
received directly from the example.com SMTP server. If there is any 
relaying, there is nothing that remains true and constant to sign.

But that is the situation we have today: My ISP's server can choose to 
refuse to accept connections from servers that are on a blacklist of 
open relays and spammers, and can, in theory, have a list of known good 
servers who authenticate their clients. If all the new header does is 
verify the sending mail server, that is done just as well by verifying 
the ip address at the time of connection.

 -- sidney

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


Re: Open Source Embedded SSL - Export Questions

2003-11-26 Thread Sidney Markowitz
As a separate issue from whether you want to implement AES, if you do 
decide to implement it look at Brian Gladman's code at 
http://fp.gladman.plus.com/cryptography_technology/rijndael/

It is the fastest free implementation of AES that I know of, and has a 
good history and credentials behind it as you can see from the 
background information linked from that web page.

 -- sidney

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


Re: Are there...one-way encryption algorithms

2003-11-19 Thread Sidney Markowitz
Enzo Michelangeli wrote:
but the slight risk of collision,
although practically negligible, is a bit irksome
If you quantify the practically negligible risk, it might be less 
irksome: SHA-1 is a 160 bit hash. The birthday paradox says that you 
would need to hash 2^80 different credit card numbers before you had a 
50% probability of having even one collision in your database keys. Very 
roughly that means you would need to have a trillion different credit 
card numbers in your database in order to get as much as a one in a 
trillion chance of a collision. You would probably find dealing with a 
trillion different credit card numbers more irksome than the negligible 
chance of a collision even that many would give you.

 -- sidney

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


Re: Attacking networks using DHCP, DNS (Updated news)

2003-06-29 Thread Sidney Markowitz
It turned out that the ISP, Charter, was not compromised. The user had 
some nasty spyware install itself on his computer. Here are the details:

http://ask.slashdot.org/comments.pl?cid=6260281sid=68266tid=172

 -- sidney



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