{"id":35447959,"url":"https://github.com/anssi-fr/ipecc","last_synced_at":"2026-01-03T02:04:04.031Z","repository":{"id":147188896,"uuid":"592778406","full_name":"ANSSI-FR/IPECC","owner":"ANSSI-FR","description":"A VHDL IP for ECC (Elliptic Curve Cryptography) hardware acceleration","archived":false,"fork":false,"pushed_at":"2025-10-23T16:22:16.000Z","size":35908,"stargazers_count":44,"open_issues_count":2,"forks_count":10,"subscribers_count":7,"default_branch":"main","last_synced_at":"2025-10-23T18:26:16.726Z","etag":null,"topics":["asic","ecc","elliptic-curve-cryptography","fpga","vhdl"],"latest_commit_sha":null,"homepage":"","language":"VHDL","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ANSSI-FR.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2023-01-24T14:16:06.000Z","updated_at":"2025-10-23T16:22:20.000Z","dependencies_parsed_at":null,"dependency_job_id":"9378e387-bd94-4e22-a257-e7733fdad03a","html_url":"https://github.com/ANSSI-FR/IPECC","commit_stats":null,"previous_names":[],"tags_count":1,"template":false,"template_full_name":null,"purl":"pkg:github/ANSSI-FR/IPECC","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ANSSI-FR%2FIPECC","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ANSSI-FR%2FIPECC/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ANSSI-FR%2FIPECC/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ANSSI-FR%2FIPECC/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ANSSI-FR","download_url":"https://codeload.github.com/ANSSI-FR/IPECC/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ANSSI-FR%2FIPECC/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28182373,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2026-01-03T02:00:06.471Z","response_time":75,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["asic","ecc","elliptic-curve-cryptography","fpga","vhdl"],"created_at":"2026-01-03T02:03:03.437Z","updated_at":"2026-01-03T02:04:04.023Z","avatar_url":"https://github.com/ANSSI-FR.png","language":"VHDL","funding_links":[],"categories":[],"sub_categories":[],"readme":"# IPECC, an open-source VHDL IP for generic elliptic curve cryptography over finite field, with emphasis on side-channel resistance\n\nCopyright (C) 2023\n\n**Authors**: Karim KHALFALLAH (\u003cmailto:karim.khalfallah@ssi.gouv.fr\u003e), Ryad BENADJILA (\u003cmailto:ryadbenadjila@gmail.com\u003e)\n\n**Contributors**: Adrian THILLARD, Emmanuel PROUFF\n\n## Introduction\n\nIPECC is a hardware IP block performing the computation of scalar multiplication $[k]P$ over elliptic curves defined in short Weierstrass form on a finite field of charasteristic $p \u003e 3$. IPECC has been developped mainly for SRAM-based FPGAs (both Xilinx and Intel-Altera) but it should also be usable as input to an ASIC flow without any kind of restriction.\n\nThe size of prime $p$, denoted ``nn`` in the code and in the remainder of this document, defines the level of cryptographic security. By definition all large numbers used for cryptographic computations are ``nn``-bit long. Parameter ``nn`` is statically defined by the designer at synthesis time and can be chosen to be any integer value. All you need for that is to edit the value of a unique HDL constant. The limitation only comes from the logical and memory ressources of your target circuit/part, as the amount of logic and memory consumed by the IP will obviously increase with the value of ``nn``. An optional feature, named *dynamic prime size* feature, allows to dynamically set the size of large numbers, provided they stay below the value statically set to parameter ``nn`` (which in this case simply becomes the maximal size allowed).\n\nIPECC is intended for production purpose as well as academic research.\n\n* While targeting an end product, it will exhibit very good performance as it relies on *Co-Z* arithmetic to reduce the area of logic by a factor of almost two without impacting throughput nor latency. Countermeasures against side-channel attacks have been designed with a *defense-in-depth* state of mind, meaning that security does not rely on one unique countermeasure but in the contrary should be based on the application of several layers of defense. Thus every countermeasure can be hardware-locked at synthesis time to enforce a hardened, secure implementation, or left software-disengageable by designer instead. Available side-channel countermeasures are: **double-and-add-always**, **address-masking of $\\mathcal{R}_0/\\mathcal{R}_1$ points** (aka anti address-bit DPA or ADPA), **address-shuffling** of the sensitive intermediate point coordinates, **blinding** (randomization of the private exponent), **Z-masking** (randomized projective coordinates) and **curve isomorphic randomization**.\nScalar multiplication is guaranteed to be **constant-time** as long as no exceptions is met during computation (like intermediate points turning to be equal or opposite when performing a point addition). IPECC comes with its own TRNG.\n\n* For academic research purpose, IPECC provides a powerful and versatile testbed to analyze side-channel and fault attacks's practicability and efficiency. All countermeasures then become optional and can be engaged or fully removed from the design, either at synthesis time or dynamically (i.e at runtime) through software configuration. Conversely, it is straightforward to force usage of part or all of the countermeasures to allow for leak measure and detection, signal-to-noise ratio measures, or active stress testing/perturbation. Debug features allow breakpoint setting and step-by-step execution. Along with trigger-out signal generation to remote instruments (e.g oscilloscopes/EM injection probes) they allow for clear isolation of specific instruction, operation or computation, pattern detection and step-by-step leak detection.\n\nIPECC architecture is very simple and allows for partial reprogrammation, as it is partially based on microcode execution of embedded software routines which can be easily edited if one wants to implement a new countermeasure or test a new attack scenario.\n\nIPECC is written in fully synthesizable VHDL. A high-level description approach has been adopted, with no explicit instanciation of any vendor dependent hardware macro, with the sole exception of multiplier-accumulators which use black-box instanciations of FPGAs' so-called *DSP blocks*.\n\nIPECC comes wrapped up as an AXI-lite interface (both 32-bit/64-bit compatible) allowing easy plug-\u0026-play integration inside any ARM or RISC-V ecosystem, e.g in SoC-FPGA designs or for ASIC prototyping. It is easily programmed through a small set of control and status registers plus optional asynchronous interrupt generation. Pre-computations involved in Montgomery representation are automatically performed by hardware upon transmission of a new value of the field prime $p$, and do not involve further operation whatsoever from software.\n\nA software driver is provided to hook-up IPECC with the **libecc** software library project (available from [github.com/libecc/libecc](https://github.com/libecc/libecc)). Together with libecc  project, for which it provides a hardware accelerator of all point level computations, IPECC provides a comprehensive and highly secured solution to implement ECC protocols like EC\\*DSA or ECDH for SoC prototyping and design.\n\nIPECC is licensed in GPLv2 and available for download from ANSSI's GitHub at ``https://github.com/ANSSI-FR/IPECC``.\n\n## Highlights\n\nThe main features of IPECC are:\n\n1. Fully synthesizable, fully compatible with all FPGA vendors/parts, as well as ASIC\n\n2. No limit to security size except that of your hardware ressources\n\n3. Very simple AXI-lite interface compatible to all AMBA-based systems\n\n4. Available countermeasures:\n\n    1. Built-in\n\n        1. Point verification as very first and very last operations\n\n        2. Anti-address bit DPA, with extra layer of shuffling on intermediate point coordinates\n\n        4. Coordinates masking (Z-masking)\n\n        5. Constant time (if no exception met)\n\n    2. Optional\n\n        1. Scalar blinding ( $k' = k + \\alpha \\times q$ ) with configurable size of $\\alpha$ (up to ``nn``)\n\n        2. Memory shuffling between each scalar bit processing\n\n        3. Curve isomorphic randomization\n\n5. Reduced silicon area thanks to Co-Z arithmetic\n\n6. Customizable number of Montgomery multipliers\n\n7. Customizable number of multiplier-accumulators per Montgomery multiplier\n\n8. Built-in TRNG design (ES-TRNG from [KU-Leuven, CHES'2018](https://tches.iacr.org/index.php/TCHES/article/view/7276))\n\n9. Automatic computation of Montgomery constants\n\n10. Optional dynamically changeable size of large numbers/security parameter\n\n11. Optional GALS (Montgomery multipliers with their own sped-up clock domain)\n\n## Hardware\n\nThe documentation on hardware [doc/ipecc.pdf](doc/ipecc.pdf) is still in progress but it includes a tutorial in appendix, targeting the Xilinx Zynq-7000 FPGAs\n(Digilent's board Arty Z7-10 is used as a hardware support of the tutorial but everything described\ncan be directly carried to Zynq-UltraScale+ circuits).\n\nThe tutorial includes customization of the IP, RTL simulation and synthesis in Vivado, and driving\nthe IP through bare-metal software as well as a testing application on top of embedded Linux.\n\nThis tutorial is also a good starting point to discover the different features and\nside-channel countermeasures of the IP.\n\n## Software\n\n### The IPECC driver\n\nThe software accompanying IPECC is mainly made of a driver in the [driver](driver) folder.\nThe main driver is in [driver/hw_accelerator_driver_ipecc.c](driver/hw_accelerator_driver_ipecc.c),\nand it exposes APIs in [driver/hw_accelerator_driver.h](driver/hw_accelerator_driver.h) consisting\nof setting curve parameters, points doubling, addition, negation, scalar multiplication, comparison, etc.\n\nThe [driver/hw_accelerator_driver_ipecc_platform.c](driver/hw_accelerator_driver_ipecc_platform.c) contains\nthe platform adherence: the driver can be compiled for a standalone mode (i.e. direct mapping of the IP\nto a physical address), or a Linux compatible mode using `DEVMEM` (`/dev/mem`) mappings or `UIO` mappings (see [here](https://www.kernel.org/doc/html/v4.12/driver-api/uio-howto.html)\nfor more information on the User IO interface).\n\nThe [driver/test_driver.c](driver/test_driver.c) file contains basic tests of the IP for the various\nAPIs. In order to compile this use the `make` command (you will need `arm-linux-gnueabihf-gcc` or equivalent\nfor targeting the Zynq platform, use the `ARM_CC` environment variable to modify your compiler).\nThis should compile three binaries `test_standalone`, `test_devmem` and `test_uio` for each platform.\n\nFinally, we also provide an emulation driver in [driver/hw_accelerator_driver_socket_emul.c](driver/hw_accelerator_driver_socket_emul.c).\nThis software layer communicates using TCP sockets with a Python server that provides an emulation of\nthe APIs offered by the \"real hardware\", namely point operations. The idea is to have a simple way\nto implement and debug programs that use the hardware API without having the hardware at hand.\nThe Python server is in [driver/emulator_server/hw_driver_socket_emul_server.py](driver/emulator_server/hw_driver_socket_emul_server.py)\nand can be directly launched on the command line:\n\n```\n$ python3 driver/emulator_server/hw_driver_socket_emul_server.py \n[+] IPECC hardware emulator started, listening on 127.0.0.1:8080\n...\n```\n\nThis will open a socket in listen mode on `localhost:8080` and will\nwait for a \"client\" connection. It is possible to compile the [driver/test_driver.c](driver/test_driver.c)\ntest file in emulation mode using the `make emulator` target: this will compile the\n`test_emul` binary that can be executed as the server client on a regular PC:\n\n```\n./test_emul \nWelcome to the driver test!\n```\n\n**NOTE1**: although the driver is ready for production use with IPECC, the debug features\nare still a work in progress as we have mainly focused on the core functionalities.\nMore specifically, breakpoints and IP internal memory dumping as well\nas TRNG debugging are not fully implemented nor tested: this will be integrated in future\nupdates.\n\n**NOTE2**: the driver has been fully tested in 32-bit mode with a 32-bit IP on Zynq 32-bit\nplatforms. Other modes (in the matrix of 32-bit or 64-bit software with 32-bit or 64-bit IP)\nare a work in progress: although the software and hardware are ready to be compiled in each mode, some\ndependencies with the AXI interface bus width must be taken into consideration (this is related to how\nthe bus controller splits memory accesses). The IPECC repository will be updated when all the test cases\nare covered and validated.\n\n\n### The IPECC integration with libecc\n\nIPECC and its driver have been integrated to the [libecc](https://github.com/libecc/libecc)\nproject where all the curve operations have been replaced with hardware\nacceleration. This showcases the usage of hardware acceleration in a full fledged\nECC library supporting various elliptic curves based signature schemes and ECDH.\n\nIn order to test IPECC with libecc, please clone the repository and **checkout the dedicated IPECC branch**:\n\n```\n$ git clone https://github.com/libecc/libecc\n$ cd libecc\n$ git checkout IPECC\n```\n\nThen fetch the driver (this will clone the current repository and place the IPECC drivers in\nthe `src/curve` folder):\n\n```\n$ make install_hw_driver\n```\n\nThen, you can compile the library with hardware acceleration by selecting the underlying platform:\n\n```\n$ make clean \u0026\u0026 CC=arm-linux-gnueabihf-gcc \\\nEXTRA_CFLAGS=\"-Wall -Wextra -O3 -g3 -mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -static\" \\\nVERBOSE=1 USE_EC_HW=1 USE_EC_HW_DEVMEM=1 USE_EC_HW_LOCKING=1 BLINDING=1 make\n$ mv build/ec_self_tests build/ec_self_tests_hw\n$ mv build/ec_utils build/ec_utils_hw\n```\n\nPlease note that `USE_EC_HW=1` selects the hardware accelerator (this is mandatory to activate the hardware acceleration backend in libecc),\nand `USE_EC_HW_DEVMEM=1` selects the DEVMEM backend (you can use `USE_EC_HW_STANDALONE=1`\nfor the standalone mode, `USE_EC_HW_UIO=1` for UIO, and `USE_EC_HW_SOCKET_EMUL=1` for the socket emulation using the Python server).\nWe also override the `CC` compiler to `arm-linux-gnueabihf-gcc` for the Zynq platform (adapt at your will depending on your\ntarget), and add some necessary extra CFLAGS for the platform (as well as a `-static` binary compilation to avoid library dependency issues).\nFinally, `USE_EC_HW_LOCKING=1` is used here for thread safety during hardware access: this flag is necessary for multi-threading.\n\nYou can compile the non-accelerated (pure software) library with removing all the hardware related toggles:\n\n```\n$ make clean \u0026\u0026 CC=arm-linux-gnueabihf-gcc \\\nEXTRA_CFLAGS=\"-Wall -Wextra -O3 -g3 -mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -static\" \\\nVERBOSE=1 BLINDING=1 make\n$ mv build/ec_self_tests build/ec_self_tests_sw\n$ mv build/ec_utils build/ec_utils_sw\n```\n\nYou can then copy the produced binaries `build/ec_self_tests_(sw|hw)` and `build/ec_utils_(sw|hw)` on the target platform and execute them.\n\nAs we can see below, the performance benchmark shows a **factor 6** on average between the pure software version\nand the hardware accelerated one. The benchmarks have been performed on a [Zynq Arty Z7](https://digilent.com/reference/programmable-logic/arty-z7/start) board (with the shuffling of memory countermeasure being disabled).\n\n```\naz7-ecc-axi:/home/petalinux# ./ec_self_tests_sw perf\n======= Performance test ========================\n[+]          ECDSA-SHA224/FRP256V1 perf: 6 sign/s and 6 verif/s\n[+]         ECDSA-SHA224/SECP192R1 perf: 9 sign/s and 9 verif/s\n[+]         ECDSA-SHA224/SECP224R1 perf: 7 sign/s and 7 verif/s\n[+]         ECDSA-SHA224/SECP256R1 perf: 6 sign/s and 6 verif/s\n...\n\naz7-ecc-axi:/home/petalinux# ./ec_self_tests_hw perf\n======= Performance test ========================\n[+]          ECDSA-SHA224/FRP256V1 perf: 34 sign/s and 32 verif/s\n[+]         ECDSA-SHA224/SECP192R1 perf: 57 sign/s and 52 verif/s\n[+]         ECDSA-SHA224/SECP224R1 perf: 44 sign/s and 39 verif/s\n[+]         ECDSA-SHA224/SECP256R1 perf: 34 sign/s and 32 verif/s\n[+]         ECDSA-SHA224/SECP384R1 perf: 16 sign/s and 15 verif/s\n[+]         ECDSA-SHA224/SECP521R1 perf: 8 sign/s and 8 verif/s\n[+]   ECDSA-SHA224/BRAINPOOLP192R1 perf: 57 sign/s and 52 verif/s\n[+]   ECDSA-SHA224/BRAINPOOLP224R1 perf: 44 sign/s and 40 verif/s \n```\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fanssi-fr%2Fipecc","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fanssi-fr%2Fipecc","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fanssi-fr%2Fipecc/lists"}