Re: Exponent 3 damage spreads...

2006-09-13 Thread Simon Josefsson
Jostein Tveit [EMAIL PROTECTED] writes:

 Anyone got a test key with a real and a forged signature to test
 other implementations than OpenSSL?

There are actually two problems to consider...

First, there is the situation by Bleichenbacher at Crypto 06 and
explained in:

http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html

That uses the fact that implementation doesn't check for data beyond
the end of the ASN.1 structure.  OpenSSL was vulnerable to this,
GnuTLS was not, see my analysis for GnuTLS on this at:

http://lists.gnupg.org/pipermail/gnutls-dev/2006-September/001202.html

Eric already posted test vectors that trigger this problem.

The second problem is that the parameters field can ALSO be used to
store data that may be used to manipulate the signature value into
being a cube.  To my knowledge, this was discovered by Yutaka Oiwa,
Kazukuni Kobara, Hajime Watanabe.  I didn't attend Crypto 06, but as
far as I understand from Hal's post, this aspect was not discussed.
Their analysis isn't public yet, as far as I know.

Both OpenSSL and GnuTLS were vulnerable to the second problem.  My
discussion of this for GnuTLS is in:

http://lists.gnupg.org/pipermail/gnutls-dev/2006-September/001205.html

When I read the OpenSSL advisory, I get the impression that it doesn't
quite spell out the second problem clearly, but if you look at the
patch to correct this:

+   /* Excess data can be used to create forgeries */
+   if(p != s+i)
+   {
+   RSAerr(RSA_F_RSA_VERIFY,RSA_R_BAD_SIGNATURE);
+   goto err;
+   }
+
+   /* Parameters to the signature algorithm can also be used to
+  create forgeries */
+   if(sig-algor-parameter
+   sig-algor-parameter-type != V_ASN1_NULL)
+   {
+   RSAerr(RSA_F_RSA_VERIFY,RSA_R_BAD_SIGNATURE);
+   goto err;
+   }
+

You'll notice that there are two added checks, one check per problem.

Test vectors for this second problem are as below, created by Yutaka
OIWA.

[EMAIL PROTECTED]:~/src/gnutls/tests$ cat pkcs1-pad-ok.pem
-BEGIN CERTIFICATE-
MIICzTCCAjagAwIBAgIJAOSnzE4Qx2H/MA0GCSqGSIb3DQEBBQUAMDkxCzAJBgNV
BAYTAkpQMRQwEgYDVQQKEwtDQSBURVNUIDEtNDEUMBIGA1UEAxMLQ0EgVEVTVCAx
LTQwHhcNMDYwOTA3MTY0MDM3WhcNMDcwOTA3MTY0MDM3WjBPMQswCQYDVQQGEwJK
UDEOMAwGA1UECBMFVG9reW8xFjAUBgNVBAoTDVRFU1QgMiBDTElFTlQxGDAWBgNV
BAMTD3d3dzIuZXhhbXBsZS5qcDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
vSpZ6ig9DpeKB60h7ii1RitNuvkn4INOfEXjCjPSFwmIbGJqnyWvKTiMKzguEYkG
6CZAbsx44t3kvsVDeUd5WZBRgMoeQd1tNJBU4BXxOA8bVzdwstzaPeeufQtZDvKf
M4ej+fo/j9lYH9udCug1huaNybcCtijzGonkddX4JEUCAwEAAaOBxjCBwzAJBgNV
HRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZp
Y2F0ZTAdBgNVHQ4EFgQUK0DZtd8K1P2ij9gVKUNcHlx7uCIwaQYDVR0jBGIwYIAU
340JbeYcg6V9zi8aozy48aIhtfihPaQ7MDkxCzAJBgNVBAYTAkpQMRQwEgYDVQQK
EwtDQSBURVNUIDEtNDEUMBIGA1UEAxMLQ0EgVEVTVCAxLTSCCQDkp8xOEMdh/jAN
BgkqhkiG9w0BAQUFAAOBgQCkGhwCDLRwWbDnDFReXkIZ1/9OhfiR8yL1idP9iYVU
cSoWxSHPBWkv6LORFS03APcXCSzDPJ9pxTjFjGGFSI91fNrzkKdHU/+0WCF2uTh7
Dz2blqtcmnJqMSn1xHxxfM/9e6M3XwFUMf7SGiKRAbDfsauPafEPTn83vSeKj1lg
Dw==
-END CERTIFICATE-

-BEGIN CERTIFICATE-
MIICijCCAfOgAwIBAgIJAOSnzE4Qx2H+MA0GCSqGSIb3DQEBBQUAMDkxCzAJBgNV
BAYTAkpQMRQwEgYDVQQKEwtDQSBURVNUIDEtNDEUMBIGA1UEAxMLQ0EgVEVTVCAx
LTQwHhcNMDYwOTA3MTYzMzE4WhcNMDYxMDA3MTYzMzE4WjA5MQswCQYDVQQGEwJK
UDEUMBIGA1UEChMLQ0EgVEVTVCAxLTQxFDASBgNVBAMTC0NBIFRFU1QgMS00MIGd
MA0GCSqGSIb3DQEBAQUAA4GLADCBhwKBgQDZfFjkPDZeorxWqk7/DKM2d/9Nao28
dM6T5sb5L41hD5C1kXV6MJev5ALASSxtI6OVOmZO4gfubnsvcj0NTZO4SeF1yL1r
VDPdx7juQI1cbDiG/EwIMW29UIdj9h052JTmEbpT0RuP/4JWmAWrdO5UE40xua7S
z2/6+DB2ZklFoQIBA6OBmzCBmDAdBgNVHQ4EFgQU340JbeYcg6V9zi8aozy48aIh
tfgwaQYDVR0jBGIwYIAU340JbeYcg6V9zi8aozy48aIhtfihPaQ7MDkxCzAJBgNV
BAYTAkpQMRQwEgYDVQQKEwtDQSBURVNUIDEtNDEUMBIGA1UEAxMLQ0EgVEVTVCAx
LTSCCQDkp8xOEMdh/jAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBQUAA4GBABsH
aJ/c/3cGHssi8IvVRci/aavqj607y7l22nKDtG1p4KAjnfNhBMOhRhFv00nJnokK
y0uc4DIegAW1bxQjqcMNNEmGbzAeixH/cRCot8C1LobEQmxNWCY2DJLWoI3wwqr8
uUSnI1CDZ5402etkCiNXsDy/eYDrF+2KonkIWRrr
-END CERTIFICATE-

[EMAIL PROTECTED]:~/src/gnutls/tests$ ../src/certtool -e  pkcs1-pad-ok.pem
Certificate[0]: C=JP,ST=Tokyo,O=TEST 2 CLIENT,CN=www2.example.jp
Issued by: C=JP,O=CA TEST 1-4,CN=CA TEST 1-4
Verifying against certificate[1].
Verification output: Verified.

Certificate[1]: C=JP,O=CA TEST 1-4,CN=CA TEST 1-4
Issued by: C=JP,O=CA TEST 1-4,CN=CA TEST 1-4
Verification output: Verified.

[EMAIL PROTECTED]:~/src/gnutls/tests$ cat pkcs1-pad-broken.pem
-BEGIN CERTIFICATE-
MIICzTCCAjagAwIBAgIJAOSnzE4Qx2H/MA0GCSqGSIb3DQEBBQUAMDkxCzAJBgNV
BAYTAkpQMRQwEgYDVQQKEwtDQSBURVNUIDEtNDEUMBIGA1UEAxMLQ0EgVEVTVCAx
LTQwHhcNMDYwOTA3MTY0MDM3WhcNMDcwOTA3MTY0MDM3WjBPMQswCQYDVQQGEwJK
UDEOMAwGA1UECBMFVG9reW8xFjAUBgNVBAoTDVRFU1QgMiBDTElFTlQxGDAWBgNV

RE: IGE mode is broken (Re: IGE mode in OpenSSL)

2006-09-13 Thread Kuehn, Ulrich
 

 -Original Message-
 From: Ben Laurie [mailto:[EMAIL PROTECTED] 
 Sent: Samstag, 9. September 2006 22:39
 To: Adam Back
 Cc: Travis H.; Cryptography; Anton Stiglic
 Subject: Re: IGE mode is broken (Re: IGE mode in OpenSSL)
 
[...]
 
 In any case, I am not actually interested IGE itself, rather 
 in biIGE (i.e. IGE applied twice, once in each direction), 
 and I don't care about authentication, I care about error 
 propagation - specifically, I want errors to propagate 
 throughout the plaintext.
 
 In fact, I suppose I do care about authentication, but in the 
 negative sense - I want it to not be possible to authenticate 
 the message.
 

Do I understand correctly? You do want that nobody is able to authenticate a 
message, however, it shall not be intelligible if manipulated with? 

Or do you want that the authentication test fails if the message has been 
tampered with?

 
 I may have misunderstood the IGE paper, but I believe it 
 includes proofs for error propagation in biIGE. Obviously if 
 you can prove that errors always propagate (with high 
 probability, of course) then you can have authentication 
 cheaply - in comparison to the already high cost of biIGE, that is.
 

I you want authentication, then authenticate. Use something with known security 
properties. So instead of running over the plaintext twice like with 
forward/backward IGE, try something like EAX, which is essentially counter mode 
with CBC-MAC for explicit authentication. Comes with proofs of security.

But then, maybe I did not understand your problem (see above).

Regards,
Ulrich

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


Re: IGE mode is broken (Re: IGE mode in OpenSSL)

2006-09-13 Thread Ben Laurie
Kuehn, Ulrich wrote:
 
 
 -Original Message- From: Ben Laurie
 [mailto:[EMAIL PROTECTED] Sent: Samstag, 9. September 2006 22:39 
 To: Adam Back Cc: Travis H.; Cryptography; Anton Stiglic Subject:
 Re: IGE mode is broken (Re: IGE mode in OpenSSL)
 
 [...]
 In any case, I am not actually interested IGE itself, rather in
 biIGE (i.e. IGE applied twice, once in each direction), and I don't
 care about authentication, I care about error propagation -
 specifically, I want errors to propagate throughout the plaintext.
 
 In fact, I suppose I do care about authentication, but in the 
 negative sense - I want it to not be possible to authenticate the
 message.
 
 
 Do I understand correctly? You do want that nobody is able to
 authenticate a message, however, it shall not be intelligible if
 manipulated with?

Correct. Minx (which is the only place I use IGE) avoids traffic marking
attacks in two ways:

a) all messages are correct

b) any attempt to mark a message results in its complete corruption

See the Minx paper, http://www.apache-ssl.org/minx.pdf.

 Or do you want that the authentication test fails if the message has
 been tampered with?

No.

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: IGE mode is broken (Re: IGE mode in OpenSSL)

2006-09-13 Thread Ben Laurie
Kuehn, Ulrich wrote:
  
 
 From: Ben Laurie [mailto:[EMAIL PROTECTED] 
 Do I understand correctly? You do want that nobody is able to 
 authenticate a message, however, it shall not be intelligible if 
 manipulated with?
 Correct. Minx (which is the only place I use IGE) avoids 
 traffic marking attacks in two ways:

 a) all messages are correct

 b) any attempt to mark a message results in its complete corruption

 See the Minx paper, http://www.apache-ssl.org/minx.pdf.

 Looks interesting! Have you looked at Ron Rivest's Chaffing and Winnowing? 

Yes. Not sure why its relevant?

-- 
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: Exponent 3 damage spreads...

2006-09-13 Thread Thor Lancelot Simon
On Mon, Sep 11, 2006 at 06:18:06AM +1000, James A. Donald wrote:
 
 3.  No one actually uses DNSSEC in the wild.

DNSSEC seems to be not-uncommonly used to secure dynamic updates,
which is not the most common DNS feature in the world but it is not
so uncommon either.


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


[EMAIL PROTECTED]: [fc-announce] CFP: Financial Cryptography 2007, Feb 12-15, 2007, Tobago (submission deadline Oct 9, 2006)]

2006-09-13 Thread R. Hirschfeld
From: Sven Dietrich [EMAIL PROTECTED]
Subject: [fc-announce] CFP: Financial Cryptography 2007, Feb 12-15, 2007, 
Tobago (submission
 deadline Oct 9, 2006)
To: [EMAIL PROTECTED]
Date: Tue, 12 Sep 2006 17:11:33 -0400 (EDT)

Dear Colleague,

   please find below the call for papers for Financial Cryptography 2007, 
Feb 12-15, 2007.. The online paper submission service is now active. 
Please visit http://fc07.ifca.ai/ for more details.

Best regards,

Sven Dietrich
Program Chair, FC 2007

- ---
Call for Papers

FC'07: Financial Cryptography and Data Security
http://fc07.ifca.ai/

Eleventh International Conference
February 12-15, 2007
Lowlands, Scarborough, Trinidad and Tobago

Submissions Due Date: October 9, 2006, 11:59pm, EDT (UTC-4)

Program Chair:  Sven Dietrich (Carnegie Mellon University)
General Chair:  Rafael Hirschfeld (Unipay)

At its 11th year edition, Financial Cryptography and Data Security (FC'07) 
is a well established and major international forum for research, advanced 
development, education, exploration, and debate regarding security in the 
context of finance and commerce. We will continue last year's augmentation 
of the conference title and expansion of our scope to cover all aspects of 
securing transactions and systems. These aspects include a range of 
technical areas such as: cryptography, payment systems, secure transaction 
architectures, software systems and tools, fraud prevention, secure IT 
infrastructure, and analysis methodologies. Our focus will also encompass 
financial, legal, business, and policy aspects. Material both on 
theoretical (fundamental) aspects of securing systems,and on secure 
applications and real-world deployments will be considered.

The conference goal is to bring together top cryptographers, data-security 
specialists, and computer scientists with economists, bankers, 
implementers, and policy makers. Intimate and colorful by tradition, the 
FC'07 program will feature invited talks, academic presentations, 
technical demonstrations, and panel discussions.

This conference is organized annually by the International Financial 
Cryptography Association (IFCA).

Original papers, surveys, and presentations on all aspects of financial 
and commerce security are invited. Submissions must have a strong and 
visible bearing on financial and commerce security issues, but can be 
interdisciplinary in nature and need not be exclusively concerned with 
cryptography or security. Possible topics for submission to the various 
sessions include, but are not limited to:

Anonymity and Privacy
Auctions
Audit and Auditability
Authentication and Identification, including Biometrics
Certification and Authorization
Commercial Cryptographic Applications
Commercial Transactions and Contracts
Digital Cash and Payment Systems
Digital Incentive and Loyalty Systems
Digital Rights Management
Financial Regulation and Reporting
Fraud Detection
Game Theoretic Approaches to Security
Identity Theft, Phishing and Social Engineering
Infrastructure Design
Legal and Regulatory Issues
Microfinance and Micropayments
Monitoring, Management and Operations
Reputation Systems
RFID-Based and Contactless Payment Systems
Risk Assessment and Management
Secure Banking and Financial Web Services
Securing Emerging Computational Paradigms
Security and Risk Perceptions and Judgments
Security Economics
Smart Cards and Secure Tokens
Trust Management
Trustability and Trustworthiness
Underground-Market Economics
Virtual Economies
Voting system security

For those interested, last year's proceedings are available from Springer.

Submission Instructions

Submission Categories

FC'07 is inviting submissions in four categories: (1) research papers, (2) 
systems and applications presentations, (3) panel sessions, (4) surveys. 
For all accepted submissions, at least one author must attend the 
conference and present the work.

Research Papers

Research papers should describe novel scientific contributions to the 
field, and they will be subject to rigorous peer review. Accepted 
submissions will be included in the conference proceedings to be published 
in the Springer-Verlag Lecture Notes in Computer Science (LNCS) series 
after the conference, so the submissions must be formatted in the standard 
LNCS format (15 page limit).

Systems and Application Presentations

Submissions in this category should describe novel or successful systems 
with an emphasis on secure digital commerce applications. Presentations 
may concern commercial systems, academic prototypes, or open-source 
projects for any of the topics listed above. Where appropriate, software 
or hardware demonstrations are encouraged as part of the presentations in 
these sessions. Submissions in this category should consist of a short 
summary of the work (1-6 pages in length) to be reviewed by the Program 
Committee, along with a short biography of the presenters. Accepted 
submissions will be presented at the conference (25 minutes per