|
| chrisco255 wrote:
| For those of us less familiar with cryptography and RSA in
| general: what are the implications if RSA is broken? What are the
| mitigations that would need to occur in its place?
| tgsovlerkhgsel wrote:
| If RSA-2048 is practically broken or breakable:
|
| The public web and code signing PKIs collapse overnight. Most
| certificate authorities use RSA-2048 either for the roots or
| intermediates. The HN site not only uses a RSA-2048 key in its
| own certificate, the CA issuing that certificate and the root
| CA issuing the intermediate also do.
|
| All data transmitted without forward secrecy on most web sites
| is compromised. Most websites nowadays use forward secrecy
| and/or ECDSA, but data sent years ago may still be of value
| (e.g. passwords) and become decryptable now.
|
| Any data (e.g. backups, past e-mails) encrypted using RSA keys
| is at risk.
|
| Any authentication system relying on RSA keys has a problem.
| This can include systems like smartcards or HSMs that are hard
| to update, software or firmware updates, etc. Banking too.
|
| Edit to add - if RSA-1024 is practically breakable but RSA-2048
| is not: some systems that relied on RSA-1024 have a problem.
| These should be rare, but sometimes legacy doesn't get updated
| until it becomes an absolute emergency. Everyone realizes that
| RSA-2048 is only a matter of time, that time is running out
| quicker than expected, and starts upgrading to ECDSA with more
| urgency. This will likely take a long time due to legacy
| hardware.
| aaomidi wrote:
| 1. We kinda knew RSA has an expiration date due to quantum
| computers. Assuming the paper is true, this just brought the
| expiration date far closer to us.
|
| 2. Major issue is going to be webpki and replaying govt
| captured encrypted communications.
|
| 3. There are a lot of abandoned servers out there that use RSA.
| There is a lot of code signing that uses RSA. There is just a
| lot of identity proven on the web that uses RSA to prove the
| identity. It's going to be a clusterfuck of identity. Again,
| assuming the paper means RSA is just completely broken.
| chrisco255 wrote:
| Does this technique for factorization by Schnorr have any
| implications for any other cryptographic methods as well (if
| confirmed)?
| dataflow wrote:
| > 1. We kinda knew RSA has an expiration date due to quantum
| computers.
|
| Only if you somehow "know" quantum computing is ever going to
| be practically realized. It may never be.
| [deleted]
| freeone3000 wrote:
| There's no real big theoretical problems in the quantum
| computer building space. There's problems of scale, and
| funding, and usual growing pains of a new industry, but
| scale went from 7 to 24 fairly quickly and all it took was
| more money. If I gave IBM $10T dollars, they could build me
| a 1024-qbit computer. Once it gets cheaper, which is the
| current problem, I don't see any reason why Azure Quantum
| (ex) wouldn't simply decrease in price to where it can be
| used practically.
| [deleted]
| [deleted]
| Laakeri wrote:
| >There's no real big theoretical problems in the quantum
| computer building space
|
| The current quantum computers are just on the edge of
| what we can simulate classically, so we can't yet rule
| out the possibility that realizing a quantum computation
| requires an exponential amount of energy in the number of
| qubits. (Though it should be noted that quantum mechanics
| predicts that this will not happen.)
| coliveira wrote:
| > it should be noted that quantum mechanics predicts that
| this will not happen
|
| There is a possibility that QM will break somewhere, but
| I wouldn't consider this very probable...
| rurban wrote:
| He didn't claim it is broken. Only that it can be broken 2x
| faster than before. RSA 4096 as recommended by the FSF is still
| secure. RSA 2048 might be breakable by the NSA. But so far we
| are at 800-1000 at risk.
| TacticalCoder wrote:
| > He didn't claim it is broken.
|
| But then there's that line: "This destroys the RSA
| cryptosystem" in the abstract of the paper.
| anonisko wrote:
| "Broken" generally isn't a binary event in cryptography.
|
| It's a continuum from "impossible to do with all the time and
| energy of the universe and the most advanced computers we have"
| to "my commodity hardware can crack it in a few minutes".
|
| The same goes for fears of quantum computing breaking current
| cryptography. It goes from effectively impossible to "yeah, we
| could break it with a few years of constant computation, which
| is plenty of time to switch to quantum resistant schemes".
| jMyles wrote:
| > "Broken" generally isn't a binary event in cryptography.
|
| If there were, for example, a way to glean a private key
| without factoring the modulus, I think we'd all agree that
| this amounts to "breaking" the system insofar as that it
| changes the applicability of the hardness assumption.
|
| On the other hand, simply achieving a faster way to factor
| the modulus is, at best, part of a continuum as you say.
| bawolff wrote:
| Well that's generally true, sometimes breakthroughs do happen
| overnight. Its not impossible.
| anonisko wrote:
| Yup. That's why I say generally.
|
| Even if the paper is correct it seems to fall into the
| 'moving down the continuum' category.
| bawolff wrote:
| This would massively break basically all traditional public key
| crypto i think (depends a bit on if it extends to eliptic-curve
| or just integer based RSA [edit: meant to say whether the
| algorithm can be adapted to solving discrete logrithms over
| eliptic curves]). It would be the biggest crypto thing to
| happen in the last 30 years at least.
|
| The mitigation would be to move to experimental post-quantum
| crypto systems immediately (quantum computers have all the fuss
| because they can break rsa).
|
| This is basically an unbelievable result. Without actually
| providing some factored numbers i am very doubtful.
|
| [I have not read paper]
|
| Edit: as pointed out below, i may have gotten overexcited.
| Still an incredible result if true.
| teraflop wrote:
| There is no such thing as "elliptic-curve RSA".
| jMyles wrote:
| > This would massively break basically all traditional public
| key crypto i think (depends a bit on if it extends to
| eliptic-curve or just integer based RSA).
|
| "A bit"? A lot more than a bit. A world.
|
| And on the surface, since it appears to be a factoring
| system, rather than a general purpose discrete log solver,
| the consequences, while incredible, are far more limited than
| the picture you paint. If this is even true; a matter over
| which I'm skeptical.
| sillysaurusx wrote:
| There are lots of alternative constructions. ECC, for example.
|
| 1024-bit and higher RSA is still unfactorable, so I don't think
| anyone will be attacking RSA directly any time soon.
| anonisko wrote:
| Reminiscent of Craig Wright's claim to be Satoshi.
|
| It doesn't matter what you claim with words if you can't back it
| up with cryptographic evidence.
|
| Shut up and prove you've done (or can do) the work.
| [deleted]
| biolurker1 wrote:
| Are you really comparing a con artist with one of the most
| famous cryptographers?
| anonisko wrote:
| Dear lord no. I can see how it might come across like that.
|
| More drawing attention to the wider theme that we generally
| should not take people at their word when we have the option
| to demand proof of work that can't be faked or mistaken.
|
| Don't trust. Verify.
| Ar-Curunir wrote:
| These are not trivial algorithms to implement, and the
| other factorization records require months of work from
| implementation experts. It's not an easy task, and theory
| work stands independently of implementation effort.
| tandr wrote:
| What does "36 bits of work" mean, sorry?
| bawolff wrote:
| My naive assumption would be, takes 2^36 cpu operations
| ISL wrote:
| If so, 2^36 ~ 7 x 10^10, so a few seconds on GHz processors.
| wtallis wrote:
| 2^36 arithmetic operations is what is claimed. That's not
| quite the same as CPU operations, because we only have 64-bit
| CPUs with up to 512-bit vector instructions, but we're
| talking about factoring 800-bit numbers. So we need to allow
| for several CPU instructions to implement each of the
| required arithmetic operations.
| jtsiskin wrote:
| Yeah I would be great if they could translate that into core-
| years to match the references they listed
| aDfbrtVt wrote:
| I'm guessing it's a shorthand for the order of units of work.
| log2(8.4E10) = 36.3 bits of operations
| tgsovlerkhgsel wrote:
| Devil's advocate: Posting the factors requires implementation
| work, then optimization, then a manageable but possibly still not
| trivial amount of resources and time - and likely a lot of trial
| and error. It is perfectly conceivable that a paper would be
| published before the implementation is actually better than a
| slower but heavily optimized approach. (I don't even try to
| understand the paper, but I've seen a mention that it's a storage
| tradeoff, which may make it a very different kind of optimization
| problem.)
|
| Do we know that the paper is definitely from Schnorr? (Edit: The
| article claims its provenance is confirmed). The "destroys the
| RSA cryptosystem" claim is now part of the paper. While anyone
| can make mistakes, I would expect such claims to be at least
| somewhat carefully checked before releasing them.
|
| Either way, I expect that we'll see either a
| retraction/correction or factors within weeks.
| TacticalCoder wrote:
| I am no cryptographer. I did implement, from the paper, Yao's
| "socialist millionaire" cryptographic protocol but... It was only
| a few lines of code and a very simple (to understand, not to come
| up with) paper.
|
| Now I just looked at that Schnorr paper and, well, I can tell you
| that I'm not going to be the one implementing it : (
| jMyles wrote:
| I'm skeptical. The paper is too tough for me to digest without
| spending days/weeks/lifetimes focusing on it (and there are many
| who can do it much faster obviously). But I think that if RSA is
| materially broken, we'll know it from movements in the ground
| (eg, sudden mysterious forged signatures) by the time a paper is
| published.
|
| I don't think that such a secret can be kept for more than a few
| minutes with immediately proceeding to runtime weaponization.
| gojomo wrote:
| I can imagine a certain pure-theorist mindset being confident
| enough in their reasoning, but not yet their coding, to report
| this first. Or, strategically holding definitive proof back as a
| hammer to deploy once the doubters reveal themselves.
|
| Why not let others do the rote reduction-to-practice?
|
| Why not create an example where your theory was correct, & your
| reputation was on the line, that took a little while to resolve -
| but when it does, it does so definitively in your favor, so you
| are more trusted in future pre-definitive-verification
| pronouncements?
|
| (I don't know enough about Schnorr-the-person to know if this
| fits his personality, but I can imagine such personalities.)
| jagger27 wrote:
| That's really all there is to it. Pudding, proof, etc.
| natch wrote:
| > the provenance of the paper has been confirmed: it is indeed
| Schnorr.
|
| What I read is that someone contacted Schnorr _over email_ to get
| this confirmation.
|
| I'm not saying the confirmation is wrong. And I'm not saying
| email cannot convey information.
| ornxka wrote:
| Well, it's definitely suspect now that RSA is broken.
| AnimalMuppet wrote:
| "Email cannot convey information"? Baloney. It does all the
| time.
|
| You seem to mean something different from what your words
| say...
| sodality2 wrote:
| Factors or gtfo
| NoKnowledge wrote:
| This take is rather naive. Those RSA factoring records were done
| by a large international team of researchers, using well
| established algorithms and decades of work on implementing those
| methods as fast as possible.
|
| The blog post says the paper mentions 8.4e10 operations for
| factoring, but I can't find that number in the paper anywhere.
| The post then states: "The 800-bit claims would be 36 bits of
| work." I don't know what that means.
|
| [edit]: the numbers are in the new version
| (https://eprint.iacr.org/2021/232). I was looking at the old
| version uploaded yesterday.
| titanomachy wrote:
| > The post states that 800-bit claims would be 36 bits of work.
| I don't know what that means.
|
| From the article: "Schnorr's paper claims to factor ... 800-bit
| moduli in 8.4*1010 operations"
|
| 2^36 ~= 8.4*1010, so I guess "36 bits of work" means 2^36
| operations. Analogous to how a password with 36 bits of entropy
| would require 2^36 guesses. My first time encountering the
| phrase "bits of work" as well, though.
| tgsovlerkhgsel wrote:
| 2^36 "operations" can still take a lot of time if each
| operation is multiplying two giant numbers, unless the meaning
| of "operation" is somehow normalized to mean e.g. 64 bit
| integer operations.
| UncleOxidant wrote:
| It didn't take long for custom ASICs for mining bitcoin to
| emerge. It wouldn't take long for custom ASICs to do these
| kinds of operations a lot faster than on a general purpose
| CPU to emerge.
| TacticalCoder wrote:
| > 2^36 "operations" can still take a lot of time if each
| operation is multiplying two giant number
|
| It took me 3.3 years of actual computation time to do about
| 2^46 multiplication+modulo of two 2048 bit numbers on a Core
| i7. 2^36 of 2048 bit numbers should be doable in a day on an
| eight years old CPU.
|
| P.S: that was on a single core, for the problem I solved was
| explicitly created as to not be parallelizable.
| libeclipse wrote:
| Supposing the paper does describe a more efficient
| factorisation algorithm, that does not imply that factoring a
| 800 bit prime (like the author of this article suggests) would
| be cheap.
| contravariant wrote:
| It's in the abstract:
|
| >Our accelerated strongprimal-dual reduction of [GN08] factors
| integers N[?]2^400 and N[?]2^800 by 4.2*10^9 and 8.4*10^10
| arithmetic operations.
| AnimalMuppet wrote:
| Increasing the length by a factor of 2^400 only increased the
| amount of work by a factor of 20? Staggering, if true in
| general.
| vitus wrote:
| Actually, you're only increasing the length of the number
| by a factor of 2, since 2^400 is a 400-bit number.
|
| If true, it's still leaps and bounds ahead of anything we
| have today, though.
| abetusk wrote:
| OK, here is a brief overview for people:
|
| To factor a number N (assumed to essentially be the product of
| two very large primes), find a 'short' lattice vector [0] using
| LLL [1] (and BKZ reduction? [2]) that finds many relations of the
| form: (u_i) = p_i,0 * p_{i,1} * ... * p_{i,n-1}
| (u_i - v_i * N) = q_{i,0} * q_{i,1} * ... * q_{i,n-1}
|
| where p,q are small primes.
|
| Numbers that have all their factors less than some prime, B, are
| said to be "B-smooth". In the above, both (u_i) and (u_i - v_i *
| N) are p_{i,n-1}-smooth and q_{i,n-1}-smooth, respectively.
|
| Construct many u_i and (u_i - v_i * N), so much so that you can
| create a product of primes, r_i, of the form:
| r_0^{2 b_0} * r_1^{2 b_1} * ... * r_{n-1}^{2 b_{n-1}} = 1 mod N
|
| where each b_i are integers.
|
| Since all exponents (2 _b_i) are even, we have the potential to
| find the square root of 1 which has the potential to resolve to
| two different numbers since N is composite. One of those is the
| product of r_i^{b_i} and the other is -1. Since y^2 = 1 mod N, we
| get (y-1)_ (y+1) = 0 mod N. If (y-1) or (y+1) are not 0, then
| then must share a factor of N and we've successfully factored.
|
| The trick is, of course, finding the smooth numbers. To do this,
| a lattice basis is made such that you find a short integer
| relation of the form a_0 ln(p_0) + a_1 ln(p_1)
| + ... + a_{n-1} ln(p_{n-1}) ~= ln(N)
|
| where ~= means "approximately equal to".
|
| u is chosen as the product of primes of all a_i > 0 and v is
| chosen to be the product of all primes where a_i < 0. The hope is
| that (u - v*N) is also p_{n-1}-smooth, which, as far as I
| understand, most of the math in the paper is trying to justify.
|
| The main innovation here, as far as I can tell, is that Schnorr
| is fiddling with the 'weighting' of the main diagonal when
| constructing the lattice basis. I interpret this as basically
| trying to randomize the initial lattice basis so that the chances
| of getting a different integer relation (for eventual
| construction of u,v) is more probable.
|
| I've been confused about this for over a decade as variants of
| this algorithm, and Schnorr's work in general, have been well
| published. For example, there's a paper from 2010 on "A Note on
| Integer Factorization Using Lattices" by Antonio Vera which
| discusses Schnorr's [3] construction.
|
| Is Schnorr trying to shout louder so people will listen or is
| there something else fundamentally flawed with this type of
| algorithm?
|
| Just a word of warning, LLL solves polynomial factorization in
| polynomial time (given a polynomial with integer coefficients,
| find it's factor polynomials also with integer coefficients) [4]
| and has been used to break other (now very old) cryptosystems
| [5]. If there's a candidate algorithm to solve integer factoring,
| lattice reduction (LLL, PSLQ, etc.) are it.
|
| I know of fplll that's a stand alone (FOSS) implementation of LLL
| and some extensions (BKZ, etc.) [6].
|
| [0] https://en.wikipedia.org/wiki/Lattice_reduction
|
| [1]
| https://en.wikipedia.org/wiki/Lenstra%E2%80%93Lenstra%E2%80%...
|
| [2]
| https://www.newton.ac.uk/files/seminar/20140509093009501-202...
|
| [3] https://arxiv.org/pdf/1003.5461.pdf
|
| [4]
| https://en.wikipedia.org/wiki/Factorization_of_polynomials#F...
|
| [5] https://web.eecs.umich.edu/~cpeikert/lic13/lec05.pdf
|
| [6] https://github.com/fplll/fplll
| titanomachy wrote:
| Thanks for summarizing, and talking about what's novel here.
|
| In the paper Schnorr suggests that this algorithm factors
| 800-bit integers in ~10^11 operations [36 bits], whereas the
| Number Field Sieve uses ~10^23 [76 bits]. Does that 76-bit
| figure represent the current state of the art, more or less?
|
| Also, since the paper talks only in terms of specific sizes of
| integers, I assume there's no claimed asymptotic speedup over
| existing methods?
| dang wrote:
| This was heavily discussed yesterday. (Edit: this next bit was
| out of date:) It seems the provenance of the paper and the
| 'destroy' claim are unclear.
|
| _"This destroys the RSA cryptosystem"_ -
| https://news.ycombinator.com/item?id=26321962 - March 2021 (140
| comments)
| john_alan wrote:
| Nah it's confirmed as from Schnorr.
|
| He even reiterated his belief it leaves RSA rekt.
|
| All that's left is the veracity of the attack.
| dang wrote:
| Ok thanks! I was out of date.
| tyingq wrote:
| Isn't it typical to release the paper first, for peer vetting,
| ahead of any actual working proof?
|
| It seems like the only reason for the _" put up or shut up"_
| reactions is that _" destroys RSA"_ comment in the submitted
| abstract...which isn't in the actual paper.
| chrisseaton wrote:
| > is that "destroys RSA" comment in the submitted
| abstract...which isn't in the actual paper
|
| I think it is - https://eprint.iacr.org/2021/232.pdf
| tyingq wrote:
| Ah, I see. It's been removed in a newer revision of the
| paper. https://www.math.uni-
| frankfurt.de/~dmst/teaching/WS2019/SVP9...
| chrisseaton wrote:
| Is that a retraction? What changed to cause that removal?
| dTP90pN wrote:
| The newer 12-page version on the preprint server has a PDF
| creation date of 3/3/2021, 11:32:56 AM, created with
| pdfeTeX-1.30.4.
|
| https://eprint.iacr.org/eprint-
| bin/getfile.pl?entry=2021/232...
|
| The previous (reportedly wrongly uploaded) version is from
| 12/5/2019, 9:10:13 AM created with pdfeTeX-1.30.4.
|
| https://eprint.iacr.org/eprint-
| bin/getfile.pl?entry=2021/232...
|
| The university website version is from 3/5/2020, 12:00:19
| PM created with pdfTeX-1.40.15.
|
| These dates & times are MM/DD/YYYY & CET.
|
| A co-editor of the Cryptology ePrint Archive confirmed the
| submission on twitter:
|
| https://twitter.com/Leptan/status/1367103240228261894
| m4lvin wrote:
| That times out for me, I guess www.math.uni-frankfurt.de is
| now getting more attention than usual ;-)
|
| Here is a version in the Google cache, it has the date of
| tomorrow on it "work in progress 04.03.2020" and no longer
| contains the "destroys RSA" sentence: https://webcache.goog
| leusercontent.com/search?q=cache:E0L-S3...
| bhaney wrote:
| Other way around I think. Your link is an old version of
| the paper. The one on eprint was just updated today with a
| version of the paper that adds the "destroys RSA" line and
| removes the "work in progress" line (put it in the wayback
| machine to see the version that was there yesterday without
| the claim of destroying RSA)
| [deleted]
| itcrowd wrote:
| The factors could be included in the manuscript as an example..
| dragontamer wrote:
| The sum-of-three cubes announcement was tweeted pretty easily.
|
| https://twitter.com/robinhouston/status/1169877007045296128
|
| Its easier to drum up support for your paper when you have a
| quick way to prove to the community of mathematicians that your
| results are golden.
|
| EDIT: The original webpage:
| http://math.mit.edu/~drew/sumsofcubes.html
|
| As you can see, the sum-of-cubes announcements are very terse.
| Ultimately pointing to the following link:
| https://share.cocalc.com/share/900eec7e-0710-4e2f-a03a-dba01...
|
| That kind of website / tweet is a "drop the mic" moment. It
| really makes people pay attention.
| coliveira wrote:
| That's not how science works. Yes, if your algorithm is
| simple enough and you can create an implementation, then it
| is good that you produce a working version. But it may be
| more complicated to implement the algorithm than writing a
| paper. This doesn't mean that the implementation is
| impossible.
| anonisko wrote:
| The whole paper is linked, https://eprint.iacr.org/2021/232.pdf
| jasonmp85 wrote:
| This is math. The working proof _is_ the paper. It just takes a
| long time to refute if there's a subtle error. "Putting up"
| ISN'T proof but it will sure get a lot of important people to
| drop what they're doing and check the paper faster.
| croddin wrote:
| How broken does this claim RSA is? SHA-1 was known to be broken
| for a long time before actually pulling off a collision was
| performed for example.[1]
|
| [1]https://en.wikipedia.org/wiki/SHA-1#Attacks
| Klwohu wrote:
| You probably understand how serious this is, so many people are
| going to become very emotional as this strikes at the very
| foundations of the Internet and digital security as we know it.
| The reactions I've seen so far do seem very emotional and this
| will only become much, much worse if there's a PoC which is
| produced.
| andrewla wrote:
| For something of this magnitude, I think the expected behavior
| would be to delay the release of the paper until the ecosystem
| had time to adapt. To prove the paper is valid (and to assert
| precedence) you would offer to factor several "nothing up my
| sleeve" numbers -- like sha512("schnorr1") +
| sha512("schnorr2").
|
| As it is, if the algorithm presented is valid then this
| potentially compromises currently operating systems.
| toast0 wrote:
| I haven't read the paper or anything, but if the expected
| adaptation is to drop support for RSA; no reasonable amount
| of time will make it a seamless transition.
|
| There are so many devices and pieces of software that are
| stuck on RSA, a headsup of say 5 years would still result in
| a clossal mess; may as well have the mess now.
| [deleted]
| dcow wrote:
| I do not agree that so-called "responsible disclosure" would
| or should be the expected behavior. I do understand how
| someone accustomed to corporate bug bounties and private
| security mailing lists may think so, though. Full disclosure
| is a perfectly reasonable strategy especially when we're
| operating in the academic realm. Industry always takes years
| to catch up to academia anyway.
| nine_k wrote:
| If this paper allows to produce a working RSA cracker in a
| month, much of high-value IT infrastructure is under
| imminent threat.
|
| Yes, you can replace your SSH keys with elliptic ones, and
| maybe adjust your TLS accepted algorithms. Even this is not
| always easy or cheap.
|
| But other things that may rely on RSA (or triple RSA) may
| have trouble upgrading fast, and upgrading them at all is
| going to cost a lot.
| coliveira wrote:
| If you find something that can break all cryptography in the
| world, then I think your best option (even for your personal
| security) is to release everything publicly.
| kybernetikos wrote:
| From a personal safety point of view?
| bhouston wrote:
| The first thing this will be used for is stealing Bitcoin and
| other cryptocurrency I predict. So watch out for your wallets.
| kinghajj wrote:
| Bitcoin wallets don't use RSA, but ECDSA.
| hn_throwaway_99 wrote:
| This was my exact argument:
| https://news.ycombinator.com/item?id=26323951
|
| Should be trivial to show a working proof on a smaller-than-usual
| RSA number if "this _really_ destroys RSA ".
| racecar789 wrote:
| I know a lot of programming languages, but I have never wrapped
| my head around math notation.
|
| Question for someone who is familiar math notation...was the
| abstract of this article easy to understand?
|
| For me, the abstract seems like code but no commentary explaining
| what each bloc does. But I could be mistaken.
| chmod775 wrote:
| > For me, the abstract seems like code but no commentary
| explaining what each bloc does. But I could be mistaken.
|
| You are mistaken. (Pretty much) all of mathematics is written
| as natural language, and those symbols are just abbreviations
| for stuff that could also be written as words. If I read those
| sentences out loud, another could write them back down and
| arrive at something that looks the same.
|
| That's why all of mathematical notation is embedded in
| sentences - they are _part_ of the sentence and can be read as
| such.
|
| Further that is really basic notation a first semester student
| of any STEM discipline should be able to read, though I
| wouldn't expect them to know what a lattice and some of the
| other terminology is.
| kfrzcode wrote:
| I'd love a "cheat sheet" or dictionary for mathematical
| notation. I don't know how to pronounce half of the embedded
| symbology, let alone what rules apply. It seems so esoteric
| and arbitrary sometimes, though I recognize it's most
| certainly not.
| woah wrote:
| You will not be able to understand the notation if you do not
| understand the math
| nightcracker wrote:
| For context: I'm a computer science MSc student.
|
| The notation is easy to understand (and as far as mathematical
| notation goes, really quite tame). I don't know what a nearly
| shortest vector of a lattice is in this context, but I do
| understand everything else. Note that means I have no idea how
| the actual method works, but I can understand what's being
| claimed.
| sterlind wrote:
| Not an expert at all, but you can think of lattices as
| evenly-spaced grid points in a vector space. Given a set of
| basis vectors b0..bn, and arbitrary integers a0..an, a0b0 +
| ... + anbn are points on the lattice b.
|
| You can have a "good basis" where the norms for b are low, or
| an equivalent "bad basis" with the same lattice points but
| with high norms. That's one hard problem (lattice reduction),
| but there are polynomial-time approximations.
|
| The shortest vector problem, iirc, is to find the vector with
| the smallest norm in the best possible basis of that lattice.
| wtallis wrote:
| The first half of the abstract is more akin to declaring the
| data types and structures used, and the second half is mostly a
| very high level summary of the overall method and results. It's
| not supposed to be interpreted like code. It's just setting up
| the context you need to start interpreting the meat of the
| paper, and giving you a heads-up about what background topics
| to Google if anything in the abstract sounds unfamiliar.
| dutchmartin wrote:
| For someone who took a matrix calculation (linear algebra)
| course like me, it was kinda understandable.
___________________________________________________________________
(page generated 2021-03-03 23:00 UTC) |