@koraa This is the fresh attempt of the PR #626 (which is closed, due to dirty worktree)

Oh and could you please improve the commit message?

Codecov Report

❌ Patch coverage is 91.11111% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.53%. Comparing base (1e6e17e) to head (3d47ec6).
⚠️ Report is 17 commits behind head on main.

@@            Coverage Diff             @@
##             main     #671      +/-   ##
==========================================
+ Coverage   86.45%   86.53%   +0.07%     
==========================================
  Files         119      120       +1     
  Lines       12705    12721      +16     
  Branches      238      240       +2     
==========================================
+ Hits        10984    11008      +24     
+ Misses       1717     1712       -5     
+ Partials        4        1       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Oh and could you please improve the commit message?

Yes sure.

@Sambit003 Could you also please fix the CI

@Sambit003 Could you also please fix the CI

Will look into it

Oh and could you please improve the commit message?

@koraa It's done

@koraa I've fixed other issues and warnings too. Please check it

@Sambit003 Thank you for your continued work on this pull request!

There are further comments from my side, but at this point I don't think its very kind to ask you to do another lengthy round of reviews.

Would you be open to setting up a time to pair up and merge this together in a video call?

@Sambit003 If you are open to it, please send me a mail so we can set up a time!

@Sambit003 Thank you for your continued work on this pull request!

There are further comments from my side, but at this point I don't think its very kind to ask you to do another lengthy round of reviews.

Would you be open to setting up a time to pair up and merge this together in a video call?

Yess ofcourse I will be in a video call with you then. But there are some file conflicts we need to sort out in pair. I'm sending you the mail.

@koraa you can delete your comment which contains your mail ID. It can lead to serious things in future. I've noted your mail ID

After a conversation with @Sambit003 I have come to the conclusion that parts of this PR are likely AI generated without properly vetting the resulting code.

Specifically, the kyber_encaps.rs file changes are…wild:

#![no_main]
extern crate arbitrary;
extern crate rosenpass;

use libfuzzer_sys::fuzz_target;

use rosenpass_cipher_traits::primitives::Kem;
use rosenpass_ciphers::EphemeralKem;

use rosenpass_to::to;

#[derive(arbitrary::Arbitrary, Debug)]
pub struct Input {
    pub pk: [u8; EphemeralKem::PK_LEN],
}

fuzz_target!(|input: Input| {
    // HALLUCINATION: This struct is defined just a few lines above this code.
    // There is no len function and if there was, we would see it in this file.
    if input.len() < 32 {
        return;
    }

    // HALLUCINATION: Kyber768Input does not exist
    let input = Kyber768Input::from(input);

    // HALLUCINATION: KYBER_CIPHERTEXT_LEN does not exist. The variable is named EphemeralKem::CT_LEN
    let mut ciphertext = [0u8; KYBER_CIPHERTEXT_LEN];
    let mut shared_secret = [0u8; 32];

    // HALLUCINATION: EphemeralKem::encaps returns Result<(), error_type>. This code is thus obviously broken:
    // 1. Error handing not present
    // 2. Return type does not implement the right To interface
    // 3. The ciphertext parameter has not been moved out of the encaps method call; it has just been duplicated into the to parameter.
    // 4. For the free-standing to(dest, src) function, dest comes first. Its supposed to behave somewhat like a variable assignment.
    to(
        EphemeralKem::encaps(&input.pk, &mut ciphertext, &mut shared_secret),
        &mut ciphertext,
    );
});

Obviously, I am not happy about this. Reviewing this pull request quite frankly has been a bit of a waste of my time.

I discussed this with @Sambit003, he will polish his PR further and perform a thorough, manual review of all code he submits before the next iteration of this PR.

This is not the first time people have submitted spurious, probably AI generated changes within the Rosenpass project; actually some of the people who did this are my friends. Whatever our personal relationship, I told them off for their own AI generated contributions. My advise for @Sambit003 and anyone else who considers using AI to generate Rosenpass PRs ist: Be honest, be open, be curious, be proactive. Ask if you have a question. And if you used AI, just say so. We are stern, and thorough but we don't bite.

This is absolutely, the sort of mistake we can get past in this case or in other similar cases. We don't forget, but we do certainly forgive, often quickly.

Speaking generally, at Rosenpass we do not have a particular policy about AI generated PRs and contributions. I use AI tools; although mostly for research tasks, not for generating code. Using AI to help a human improve Rosenpass absolutely is acceptable, but contributors are expected to take as much responsibility of their contributions when using AI as they would take when using any other kind of tools.

We do read and understand every single line of code in a PR. For every change, no matter how small, we need a reason of why it was made and what it does. We expect the same level of diligence from contributors.

If achieving this level of diligence is beyond the abilities of a contributor, we expect them to flag this openly and we absolutely willing to build a support structure for contributors earlier in the programming journey. We can only provide this support structure, if we know its needed.