Re: quantum chip built

2006-01-17 Thread Michael Cordover



John Denker wrote:

[EMAIL PROTECTED] wrote:
From what I understand simple quantum computers can easily brute-force 
attack RSA keys or other
types of PK keys.  


My understanding is that quantum computers cannot easily do anything.



Au contraire, quantum computers can easily perform prime factoring or 
perform discrete logarithms - this is Shor's algorithm and has been 
known for more than a decade.  The difficulty is in making a QC.





Is ECC at risk too?  And are we at risk in 10, 20 or 30 years from now?




ECC is also at risk because it relies on the difficulty of discrete 
logarithms which are victim to a quantum attack.  Are we at risk in 10, 
20 or 30 years?  Well, as John said, it's hard to say.  The first 
working 2 qbit computers were demonstrated in 1998, then 3 qbits in the 
same year.  7 qbits were demonstrated in 2000.  8 in December 2005.  As 
you can see, adding a qbit is pretty hard.  In order to factor a 1024 
bit modulus you'd need a 1024 bit QC.  Perhaps if there were some sudden 
breakthrough it'd be a danger in a decade - but this is the same as the 
risk of a sudden classical breakthrough: low.


My assessment: nothing to worry about for now or in the immediate 
future. A key valid for 20 years will face much greater dangers from 
expanding classical computer power, weak implementations, social 
engineering etc.  The quantum chip is just a new housing, not anything 
that puts RSA or ECC at risk.


Regards,

Michael Cordover
--
http://mine.mjec.net/

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


Re: What happened with the session fixation bug?

2005-06-05 Thread Michael Cordover


James A. Donald wrote:
| Adversary accesses web site as if about to log in, gets
| a session ID.  Then supplies false information to
| someone else's browser, causes that browser on some one
| else's computer to use that session ID.  Someone else
| logs in with hacker's session ID, and now the adversary
| is logged in.

An excellent plan and the reason sessions shouldn't be automatically
given to every user of a site.  In my experience though, sessions aren't
created until the login button is pressed - the malicious user needs
an existing account.  This might then become a permissions escalation
problem - emphasis on the might.

Question: how does one convince the victim's browser to use the
malicious ID?  And if one can modify cookies on the browser for a remote
site (what needs to be done in most cases), doesn't this raise much more
serious questions about XSS?  I think this is probably a low-impact
issue unless sessions are used improperly.  Then again, given some web
apps I've seen, might be high impact :/.

Regards,

Michael Cordover

--
http://mine.mjec.net/
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]