Update Falcon verification to use `horner_eval_base` #1661

Al-Kindi-0 · 2025-02-11T13:02:55Z

As the title says. The current cycle count is around 57500 cycles.

plafer

LGTM! Great job 👏

Left a few nits

plafer · 2025-02-14T12:25:51Z

stdlib/tests/crypto/falcon.rs

 #[test]
 fn test_falcon512_probabilistic_product_failure() {
-    // Create a polynomial pi that is not equal to h * s2.
+    // create a polynomial pi that is not equal to h * s2.


The random_coefficients use rng - can we either fix a seed, or generate those coefficients deterministically?

plafer · 2025-02-14T12:39:09Z

stdlib/asm/crypto/dsa/rpo_falcon512.masm

+    adv_push.2 
+    dup.1 dup.1 ext2inv
+    push.0.0
+    loc_storew.4


nit: can we add the state of the stack after this block?

plafer · 2025-02-14T12:40:12Z

stdlib/asm/crypto/dsa/rpo_falcon512.masm

@@ -218,182 +207,83 @@ export.load_h_s2_and_product.4
        push.M u32lt assert
        push.M u32lt assert

+        horner_eval_base


can we also add some comments for the state of the stack in this loop? It's quite hard to follow

plafer

I ran the miden-base tests on top of this branch, and I'm getting some NotU32 errors (for example, with the scripts::p2id::prove_consume_multiple_notes test).

Would be good to make sure the bus works fine too after we fix those (and #1664 might be useful if there's a bug there)

plafer

My bad, miden-base reimplements the dsa::falcon_sign method which was updated in this PR. After updating it, all tests pass.

I also confirmed that the bus is fixed with this PR, which confirms the findings of #1664 that rcombbase was the problem.

bobbinth

Looks good! Thank you! I left a few comments inline - most are pretty small.

processor/src/host/dsa.rs

stdlib/tests/crypto/falcon.rs

stdlib/asm/crypto/dsa/rpo_falcon512.masm

bobbinth · 2025-02-24T08:33:11Z

stdlib/asm/crypto/dsa/rpo_falcon512.masm

-    padw
-
-    # For mem_stream
+    # 5) Load s2 and evaluate at tau_inv (Due to the final norm test we do not need to range check the s2 coefficients)


Do we explain somewhere in more detail why doing the final norm testing means no meed to range-check s2 coefficients?

I spent some time investigating this and it seems that the argument justifying this comment no longer holds. I think this is a result of the recent changes or maybe even earlier.
Looking at the norm_sq procedure too, we are doing there a u32lt which would have undefined behavior if the input is not already checked to be a u32, so we should at least have a u32 check on the coefficients of s2.
I have now added bound checks on the coefficients of s2 similar to those on h.
This has unfortunately led to an increase in the number of cycles, the current cycle count is just shy of 60000 cycles. We can comeback to this to see if we can optimize these checks.

Makes sense! Yeah - let's create an issue to figure out if we can do this range checking more efficiently somehow.

Created one here #1672

stdlib/asm/crypto/dsa/rpo_falcon512.masm

bobbinth · 2025-02-24T08:44:15Z

One other thing, before merging this PR we'd need to update miden-base to make sure the advice state value generation for the Falcon signature works similar to what we have here now, right?

Al-Kindi-0 · 2025-02-24T13:43:57Z

One other thing, before merging this PR we'd need to update miden-base to make sure the advice state value generation for the Falcon signature works similar to what we have here now, right?

Indeed, we have now changed how and what advice is provided for the signature.

bobbinth

Looks good! Thank you! I left some more comments inline - these are mostly doc-related.

Also, would you mind making a parallel PR in miden-base?

bobbinth · 2025-02-24T18:57:00Z

processor/src/host/dsa.rs

@@ -8,11 +10,13 @@ use crate::ExecutionError;
 /// vector of values to be pushed onto the advice stack.
 /// The values are the ones required for a Falcon signature verification inside the VM and they are:


nit: let's add a newline above this line.

bobbinth · 2025-02-24T18:58:58Z

processor/src/host/dsa.rs

+/// 4. The challenge point at which we evaluate the three aforementioned polynomials to check the
+///    product relationship.


Doesn't the challenge point come first? I think we should lay this out the way it is laid out in the returned vector (and probably make this explicit in the comments). This way, we'll know that the first 2 elements of the returned vector are the challenge point, the next 512 are the $h$ polynomial etc.

Agreed, changed it now

bobbinth · 2025-02-24T19:08:54Z

stdlib/asm/crypto/dsa/rpo_falcon512.masm

+    # 2. 4..8 the inverse of the evaluation point tau as [tau_inv0, tau_inv1, 0, 0],
+    # 3. 8..12 the evaluation point tau as [tau0, tau1, 0, 0],


Why not store them next to each other - e.g., as [tau_inv0, tau_inv1, tau0, tau1]? Or does this create complications somehow?

it is mentally easier to store them in separate words but no other reason than that.
Changed it now to store both in the same word as well as updated the code to take that into account.

bobbinth · 2025-02-24T19:12:56Z

stdlib/asm/crypto/dsa/rpo_falcon512.masm

    exec.load_h_s2_and_product
-    #=> [tau1, tau0, tau_ptr, MSG, NONCE1, NONCE1, ...]      (Cycles: 5050)
+    #=> [MSG, ...]                                  (Cycles: 6780)


Question: why does this say "6780" cycles while cycle count for load_h_s2_and_product procedure says "4430"?

Forgot to update the cycle count there. Updated now

bobbinth · 2025-02-24T19:13:54Z

stdlib/asm/crypto/dsa/rpo_falcon512.masm

+#! - h_i are the coefficients of the expanded public key polynomial.
+#! - s2_i are the coefficients of the signature polynomial.
+#! - pi_i are the coefficients of `h * s2` in Z_Q[x] where Q is the Miden VM prime.
+#! - nonce_i are field elements representing the nonce associated to the signature.


Should we also describe what "tau" is here?

Added a short description

bobbinth · 2025-02-24T19:56:57Z

stdlib/asm/crypto/dsa/rpo_falcon512.masm

+    ## a) Set up the accumulator for `horner_eval_base` and the memory pointers
+    push.0.0
+    locaddr.4
+    movup.3


Could we add stack state after this instruction?

bobbinth · 2025-02-24T19:57:12Z

stdlib/asm/crypto/dsa/rpo_falcon512.masm

+    adv_push.2 
+    dup.1 dup.1 ext2inv
+    push.0.0
+    loc_storew.4


Could we add stack state after this instruction?

bobbinth · 2025-02-24T19:57:36Z

stdlib/asm/crypto/dsa/rpo_falcon512.masm

+        u32overflowing_sub.M assert drop
+        u32overflowing_sub.M assert drop
+
+        horner_eval_base

        hperm
    end


Could we add stack state after this loop?

bobbinth · 2025-02-24T19:57:56Z

stdlib/asm/crypto/dsa/rpo_falcon512.masm

+
+    ## a) Reset the accumulator, update the pointers and set up the state of the hasher
+    push.0 movdn.6
+    push.0 movdn.6
    padw padw


Could we add stack state after this instruction?

Al-Kindi-0 · 2025-02-25T08:07:13Z

Also, would you mind making a parallel PR in miden-base?

Sure thing, will open one soon

bobbinth mentioned this pull request Feb 12, 2025

Improve Falcon DSA using Horner #1628

Closed

bobbinth requested review from plafer and bobbinth February 12, 2025 08:26

This was referenced Feb 13, 2025

Introduce Horner evaluation ops #1656

Merged

Fix chiplets bus #1664

Merged

plafer approved these changes Feb 14, 2025

View reviewed changes

plafer requested changes Feb 14, 2025

View reviewed changes

plafer approved these changes Feb 14, 2025

View reviewed changes

Al-Kindi-0 force-pushed the al-introduce-horner-eval-ops branch from cec1812 to 6fcd075 Compare February 24, 2025 08:27

bobbinth reviewed Feb 24, 2025

View reviewed changes

Al-Kindi-0 force-pushed the al-introduce-horner-eval-ops branch from 6fcd075 to 3402f34 Compare February 24, 2025 08:44

Base automatically changed from al-introduce-horner-eval-ops to next February 24, 2025 08:58

Al-Kindi-0 force-pushed the al-update-falcon-with-horner branch 2 times, most recently from 66cfab3 to 4c3f3a4 Compare February 24, 2025 14:16

bobbinth approved these changes Feb 24, 2025

View reviewed changes

Al-Kindi-0 mentioned this pull request Feb 25, 2025

Computing the norm of Falcon signature polynomial $s_2$ #1672

Open

Al-Kindi-0 added 5 commits February 25, 2025 09:19

feat: update Falcon verification procedure to use horner_eval_base

3bfe98e

doc: update changelog and re-comment

f2d1004

fix: clippy

600ace1

chore: address comments

9103d37

chore: address feedback

f330f6c

Al-Kindi-0 force-pushed the al-update-falcon-with-horner branch from a037d70 to f330f6c Compare February 25, 2025 08:20

Al-Kindi-0 mentioned this pull request Feb 25, 2025

Update advice provided to Falcon signature verification 0xPolygonMiden/miden-base#1183

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update Falcon verification to use `horner_eval_base` #1661

Update Falcon verification to use `horner_eval_base` #1661

Al-Kindi-0 commented Feb 11, 2025

plafer left a comment

plafer Feb 14, 2025

plafer Feb 14, 2025

plafer Feb 14, 2025

plafer left a comment •

edited

Loading

plafer left a comment

bobbinth left a comment

bobbinth Feb 24, 2025

Al-Kindi-0 Feb 24, 2025

bobbinth Feb 24, 2025

Al-Kindi-0 Feb 25, 2025

bobbinth commented Feb 24, 2025

Al-Kindi-0 commented Feb 24, 2025

bobbinth left a comment

bobbinth Feb 24, 2025

Al-Kindi-0 Feb 25, 2025

bobbinth Feb 24, 2025

Al-Kindi-0 Feb 25, 2025

bobbinth Feb 24, 2025

Al-Kindi-0 Feb 25, 2025

bobbinth Feb 24, 2025

Al-Kindi-0 Feb 25, 2025

bobbinth Feb 24, 2025

Al-Kindi-0 Feb 25, 2025

bobbinth Feb 24, 2025

Al-Kindi-0 Feb 25, 2025

bobbinth Feb 24, 2025

Al-Kindi-0 Feb 25, 2025

bobbinth Feb 24, 2025

Al-Kindi-0 Feb 25, 2025

bobbinth Feb 24, 2025

Al-Kindi-0 Feb 25, 2025

Al-Kindi-0 commented Feb 25, 2025

		@@ -8,11 +10,13 @@ use crate::ExecutionError;
		/// vector of values to be pushed onto the advice stack.
		/// The values are the ones required for a Falcon signature verification inside the VM and they are:

		/// 4. The challenge point at which we evaluate the three aforementioned polynomials to check the
		/// product relationship.

		# 2. 4..8 the inverse of the evaluation point tau as [tau_inv0, tau_inv1, 0, 0],
		# 3. 8..12 the evaluation point tau as [tau0, tau1, 0, 0],

Update Falcon verification to use horner_eval_base #1661

Are you sure you want to change the base?

Update Falcon verification to use horner_eval_base #1661

Conversation

Al-Kindi-0 commented Feb 11, 2025

plafer left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

plafer left a comment • edited Loading

Choose a reason for hiding this comment

plafer left a comment

Choose a reason for hiding this comment

bobbinth left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bobbinth commented Feb 24, 2025

Al-Kindi-0 commented Feb 24, 2025

bobbinth left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Al-Kindi-0 commented Feb 25, 2025

Update Falcon verification to use `horner_eval_base` #1661

Update Falcon verification to use `horner_eval_base` #1661

plafer left a comment •

edited

Loading