Hello.
We have created a BOINC project which is going to crack RSA 1024. We need this key to unlock our unjustly locked smartphone - Motorola Milestone. Android is a open source operating system and it should be free. We don't understand why Motorola has made such terrible thing. Other manufacters don't have problem with it. Well, because of this, we can't modify our system: correct bugs, update it to the lastest verion.

AndrOINC is a quite new project, but it already has more than 2 thousand running computers with more than 11TFlops power. We have problem with alghorithm. Someone said that current would take several ages to crack it.
We saw that your project is getting very well with factorizing high numbers. Is there any way so you can help us, help the big Android community and Milestone's users?

I see two solutions. The first one is to provide us information about your alghorithm so we can fast change it and make in our project. Second one is that you can add this key to your project and our all users can migrate here.

We'd be glad for reply.

Sorry, RSA-1024 is current out of reach of this and all other open factoring projects. While trial factoring will succeed, it will most likely take longer than the current age of the universe. Your only real hope is to exploit a hardware weakness, as in http://www.merit.edu/events/mmc/pdf/2010_pellegrini.pdf, or buy another phone. An HTC perhaps?

Are you sure that even with your alghorithm, thousands of computers and GPU support it will still take ages? I thought that sieve is a really fast method so we can crack RSA 1024 with huge power(~4000 computrs working on it) within few years..

Are you sure that even with your alghorithm, thousands of computers and GPU support it will still take ages? I thought that sieve is a really fast method so we can crack RSA 1024 with huge power(~4000 computrs working on it) within few years..

In a gnfs factoring project, the result of the sieving effort
is a sparse matrix problem, that has to be solved to break the
key. Computations on the matrix problem (even in the distributed
version used to break RSA768) are parallel, with heavy data transfer
between compute nodes --- that is to say, an expensive supercomputer
calculation. NFS@Home is currently working on 1024-bit SNFS, while
RSA keys require GNFS. There has recently been a five-or-more year
gap between the SNFS record and the corresponding GNFS record for
the same number of bits. So SNFS768 was set in 2000, RSA768 in
Dec 2009; SNFS512 in 1993, RSA512 in 1999. For 1024-bits, SNFS1024
was first broken in 2007, but not by a public project.

Switching from bits to digits, 768-bits is 233-decimal and 1024-bits
is 310-decimal (resp. 512-bits, 155-decimal). NFS@Home has been working
up towards the 310-digit _public_ SNFS record, and most recently broke
295-digits (Nov 29, 2010). The matrix for 300-digits is currently running
under a terragrid grant --- for example, previous sparse matrices from
NFS@Home were run on the first of these two clusters

http://www.tacc.utexas.edu/resources/hpc/

The software being used has not been tested in this range --- we're
the first. And that's 295-digit, 300-digit and then 310-digit, for
public SNFS. And then another 5-10 years from SNFS to GNFS, on a
computer that hasn't been built yet.

Hope this clarifies matters. -bdodson*