[Cado-nfs-discuss] problem while factoring RSA-129

Roberto Zanasi zanasi.roberto at fermi.mo.it
Wed Mar 28 08:40:20 CEST 2018


Ok, thank you very much for your efforts.

On Wed, Mar 28, 2018 at 8:33 AM, Emmanuel Thomé <Emmanuel.Thome at inria.fr>
wrote:

> Ok, I've found your problem.
>
> You're using a 32-bit machine.  ssize_t, which is used here and there, is
> good only for 31-bit signed values. We should have used off_t there (and
> we should have had #define _FILE_OFFSET_BITS 64 in cado.h, so that off_t
> is a 64-bit type).
>
> While this analysis may lead to a fix for the dup1 program, the
> perspective is quite bleak. I confess that throughout the code, we
> (collectively) have always thought that either:
>  - (s)size_t is always large enough
>  - any serious computation uses 64-bit anyway
>  - nobody uses 32-bit machines
> or sometimes combinations of the above.
>
> Bottom line: I think one would need a huge amount of time to fix cado-nfs
> so that computations above 120 digits run correctly on 32-bit machines,
> given the pervasiveness of the above considerations: after dup1, you'd
> probably hit similar issues in other filtering binaries, in linear
> algebra, and so on.
>
> 32-bit platforms are among the routinely tested platforms for cado-nfs,
> but the keyword here is "tested". We do such tests to catch compilation
> errors, idiosyncrasies that may be dangerous in the long run, etc. 32-bit
> platforms, really, aren't intended for large computations (admittedly,
> rsa-129 barely qualifies as large, but still, it's too large for 32-bit
> cado-nfs, sorry).
>
> Regards,
>
> E.
>
> On Tue, Mar 27, 2018 at 02:38:40PM +0200, Emmanuel Thomé wrote:
> > I think it would be best to move this discussion off-list.
> > E.
> >
> > On Tue, Mar 27, 2018 at 02:34:18PM +0200, Paul Zimmermann wrote:
> > >        Roberto,
> > >
> > > >  Just to be sure, did you check that all the files that this command
> is
> > > >  trying to access are indeed present in the working directory ?
> > > >
> > > > Yes, they are all present. (The /tmp directory contains 75 .gz
> files, while
> > > > c130.dup1.filelist.1 contains 74 files).
> > >
> > > did you try with revision 5a17a43 as advised by Emmanuel?
> > >
> > > What happens if you run manually the line "... antebuffer 24 ..." in
> c130.dup1.stderr.1,
> > > with the final "| gzip -dc -" ? (Maybe redirecting the output to
> /dev/null.)
> > >
> > > Same question by replacing "... antebuffer 24" by "zcat", and removing
> > > the final "| gzip -dc -".
> > >
> > > It might be that one of the .gz files is corrupted.
> > >
> > > >  The policy of the system regarding the automatic clean-up of /tmp
> can
> > > >  vary, but in any case, files in there are not guaranteed to stay for
> > > >  long. For a factorization that takes a bit long, it is better to
> use a
> > > >  working directory in a more persistent place.
> > > >
> > > > How can I change the working directory?
> > >
> > > simply with cado-nfs.py ... workdir=...
> > >
> > > Paul Zimmermann
> > > _______________________________________________
> > > Cado-nfs-discuss mailing list
> > > Cado-nfs-discuss at lists.gforge.inria.fr
> > > https://lists.gforge.inria.fr/mailman/listinfo/cado-nfs-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/cado-nfs-discuss/attachments/20180328/19a61dff/attachment.html>


More information about the Cado-nfs-discuss mailing list