deardaniel/secdata-raw huggingface dataset:
Open Quantum Safe Library Documentation: README

# Zephyr Project Port

liboqs can be used as a module for the [Zephyr RTOS](https://www.zephyrproject.org/). 

## Installation 

You have to add liboqs to your West workspace using a [West Manifest](https://docs.zephyrproject.org/latest/develop/west/manifest.html#west-manifests)

In your manifest file (`west.yml`), add the following:
```
remotes:
    # <other remotes>
    - name: liboqs
      url-base: https://github.com/open-quantum-safe

projects:
    # <other projects>
    - name: liboqs
      path: modules/crypto/liboqs
      revision: main
      remote: liboqs
```

After adding the new information to your manifest file, run `west update` to download and install liboqs as a Zephyr module. After that, you can use it in your projects.

Currently, Zephyr versions 3.4 and 3.5 are supported. Please feel free to open an issue or a PR in case you need another version supported (without guarantee that older versions can be supported at all).

## Usage

### Disclaimer regarding random number generation

In order to properly use the Zephyr port of liboqs, you have to provide a custom callback function for random number generation using the `OQS_randombytes_custom_algorithm()` API. Otherwise, all key generation and signing operations will fail.

In the two provided sample applications (also see [Samples](#Samples)), a callback is set using the default `sys_rand_get()` method from Zephyr. This method, however, does **not** provide random data suitable for cryptographic operations and is only good for testing purposes. Make sure to use a proper entroy source from your hardware to obtain actual random data.   

### Configuration

The port provides a variety of configurable options using Kconfig. Once you have the liboqs module enabled with `CONFIG_LIBOQS=y`, you can manually enable or disable specific KEM or Signature algorithms using the `LIBOQS_ENABLE_KEM_xxx` and `LIBOQS_ENABLE_SIG_xxx` options.

The algorithms to be standardized by NIST are enabled by default, all others are disabled by default.

### Supported architectures

At the moment, the following architectures are supported with the Zephyr port:
* 32-bit ARM
* 64-bit ARM
* x86
* Native Posix

Other architectures supported by Zephyr are not supported with this port, as liboqs itself doesn't support these architectures (the modules can't be enabled in those cases). Please feel free to raise an issue or PR in case a new architecture is required.

### Samples

Two sample applications are provided, demonstrating the usage of the library from within Zephyr. See [`samples/KEMs`](https://github.com/open-quantum-safe/liboqs/tree/main/zephyr/samples/Signatures) and [`samples/Signatures`](https://github.com/open-quantum-safe/liboqs/tree/main/zephyr/samples/KEMs).
Open Quantum Safe Library Documentation: CMakeLists

# SPDX-License-Identifier: MIT

cmake_minimum_required(VERSION 3.20.0)

set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
set(NO_BUILD_TYPE_WARNING ON)

find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})

project(liboqs_kems)

target_sources(app PRIVATE
    src/main.c
)
Open Quantum Safe Library Documentation: CMakeLists

# SPDX-License-Identifier: MIT

cmake_minimum_required(VERSION 3.20.0)

set(NO_BUILD_TYPE_WARNING ON)

find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})

project(liboqs_signatures)

target_sources(app PRIVATE
    src/main.c
)
Open Quantum Safe Library Documentation: README

# Known Answer Test (KAT) Sources

This directory contains the expected SHA256 hash values used to verify deterministic Known Answer Test (KAT) outputs for liboqs algorithms.

## Directory Structure

- `kem/` — Key Encapsulation Mechanisms
- `sig/` — Digital signature schemes
- `sig_stfl/` — Stateful signature schemes

Each subdirectory contains a `kats.json` file storing expected SHA256 hashes for each supported algorithm.

## Verification Process

The test programs `kat_kem`, `kat_sig`, and `kat_sig_stfl` generate deterministic outputs for each algorithm. During testing:

1. The executable is run for a specific algorithm.
2. Output is normalized to Unix-style line endings.
3. A SHA256 hash of the output is computed.
4. The hash is compared against the corresponding value stored in the appropriate `kats.json` file.

This ensures deterministic behavior and cross-platform consistency.

## Source of KAT Values

For algorithms that participated in the NIST Post-Quantum Cryptography (PQC) standardization process, the KAT procedures follow the NIST submission requirements.

Not all algorithms in liboqs were part of the NIST PQC process. In particular, stateful signature schemes were not included in the NIST PQC standardization. Their KAT values are generated based on the deterministic behavior defined by their respective implementations within liboqs. 
The `kat_sig_stfl` test program produces deterministic outputs for these algorithms, and the resulting SHA256 hashes are stored in `sig_stfl/kats.json`.

If changes are made to KAT generation logic or algorithm implementations, the corresponding hash values in the `kats.json` files must be regenerated.
Awesome Incident Response Resources: contributing

# Contribution Guidelines

Please ensure your pull request adheres to the following guidelines:

- Search previous suggestions before making a new one, as yours may be a duplicate.
- Only Incident Response tools.
- Make an individual pull request for each suggestion.
- Use the following format: ` [RESOURCE](LINK) - DESCRIPTION `
- The pull request and commit should have a useful title.
- Titles should be [capitalized](http://grammar.yourdictionary.com/capitalization/rules-for-capitalization-in-titles.html).
- List is organised by alphabetical order, please place in appropriate position. 

Thank you for your suggestions!
Unix-like Artifacts Collector Documentation: LICENSES

# Licenses

Use of the following Third-Party Software is subject to the license agreements at the URLs listed in the table below.

|Product|Copyright|URL|
|---|---|---|
|AVML|Use rights in accordance with the information displayed at: <https://github.com/microsoft/avml/blob/main/LICENSE>|<https://github.com/microsoft/avml>|
|date_to_epoch.pl|Use rights in accordance with the information displayed at: <https://github.com/tclahr/date_to_epoch.pl/blob/main/LICENSE>|<https://github.com/tclahr/date_to_epoch.pl>|
|dirwalk.sh|Use rights in accordance with the information displayed at: <https://github.com/tclahr/dirwalk.sh/blob/main/LICENSE>|<https://github.com/tclahr/dirwalk.sh>|
|find.pl|Use rights in accordance with the information displayed at: <https://github.com/tclahr/find.pl/blob/main/LICENSE>|<https://github.com/tclahr/find.pl>|
|linux_procmemdump.sh|Use rights in accordance with the information displayed at: <https://creativecommons.org/licenses/by-sa/4.0>|<https://github.com/halpomeranz/dfis>|
|stat.pl|Use rights in accordance with the information displayed at: <https://github.com/tclahr/stat.pl/blob/main/LICENSE>|<https://github.com/tclahr/stat.pl>|
|statf|Use rights in accordance with the information displayed at: <https://github.com/tclahr/statfgit/blob/main/LICENSE>|<https://github.com/tclahr/statf>|
|statx|Use rights in accordance with the information displayed at: <https://github.com/tclahr/statx/blob/main/LICENSE>|<https://github.com/tclahr/statx>|
|strings.sh|Use rights in accordance with the information displayed at: <https://github.com/tclahr/strings.sh/blob/main/LICENSE>|<https://github.com/tclahr/strings.sh>|
|timeout.sh|Use rights in accordance with the information displayed at: <https://github.com/tclahr/timeout.sh/blob/main/LICENSE>|<https://github.com/tclahr/timeout.sh>|
|zip|Use rights in accordance with the information displayed at: <https://infozip.sourceforge.net/license.html>|<https://infozip.sourceforge.net>|
Unix-like Artifacts Collector Documentation: DCO 1.1

Developer's Certificate of Origin 1.1

       By making a contribution to this project, I certify that:

       (a) The contribution was created in whole or in part by me and I
           have the right to submit it under the open source license
           indicated in the file; or

       (b) The contribution is based upon previous work that, to the best
           of my knowledge, is covered under an appropriate open source
           license and I have the right under that license to submit that
           work with modifications, whether created in whole or in part
           by me, under the same open source license (unless I am
           permitted to submit under a different license), as indicated
           in the file; or

       (c) The contribution was provided directly to me by some other
           person who certified (a), (b) or (c) and I have not modified
           it.

       (d) I understand and agree that this project and the contribution
           are public and that a record of the contribution (including all
           personal information I submit with it, including my sign-off) is
           maintained indefinitely and may be redistributed consistent with
           this project or the open source license(s) involved.
Unix-like Artifacts Collector Documentation: README

Place your validated executables (binary files and scripts) here!

In most cases, the executables should be placed in the '[UAC_DIRECTORY]/bin' directory,
along with any additional support files it needs to run.

For example, if you have an artifact that uses an executable named 'my_script.sh', you should place
this binary in the '[UAC_DIRECTORY]/bin' directory.

In the case where you have executables with the same name, but for multiple operating systems,
they should be placed in the '[UAC_DIRECTORY]/bin/[OS]' directory.

For example, if you have an artifact that uses an executable named 'lsof', but you
have two binary files, one for Linux and one for FreeBSD, you should place the binaries
in the '[UAC_DIRECTORY]/bin/linux' and '[UAC_DIRECTORY]/bin/freebsd' directories.
Note that the operating system name must be in lowercase.

In the case where you have executables that can be run on multiple operating systems, they
should be placed in the '[UAC_DIRECTORY]/bin/[OS1_OS2_OS3]' directory. Note that you
can have multiple operating systems separated by an underscore '_'.

For example, if you have an artifact that uses an executable named 'netstat' that
runs on both Linux and ESXi systems, you should place the binary either in the
'[UAC_DIRECTORY]/bin/linux_esxi' directory, or place the binary in the '[UAC_DIRECTORY]/bin/linux' and
'[UAC_DIRECTORY]/bin/esxi' directories.

In the case where you have executables with the same name, but for multiple operating systems
and multiple architectures, they should be placed in the '[UAC_DIRECTORY]/bin/[OS]/[ARCH]' directory.

For example, if you have an artifact that uses an executable named 'ss', but you
have binary files for Linux arm64 and ppc64, FreeBSD i386, and Solaris x86_64 and sparc64,
you should place the binary files in the '[UAC_DIRECTORY]/bin/linux/arm64',
'[UAC_DIRECTORY]/bin/linux/ppc64', '[UAC_DIRECTORY]/bin/freebsd/i386',
'[UAC_DIRECTORY]/bin/solaris/x86_64' and '[UAC_DIRECTORY]/bin/solaris/sparc64' directories.
Incident Response Methodologies (CERT SG): README

![CERT Societe Generale Logo](CERT_SocieteGenerale_Logo.jpg  "CERT Societe Generale Logo")


IRM-2022 (Incident Response Methodologies 2022)
=====================================

CERT Societe Generale with the collaboration of CERT aDvens provides easy to use operational incident best practices. These cheat sheets are dedicated to incident handling and cover multiple fields in which a CERT team can be involved. One IRM exists for each security incident we're used to dealing with.

CERT Societe Generale would like to thank [SANS](https://www.sans.org/) and [Lenny Zeltser](https://zeltser.com/cheat-sheets/) who have been a major source of inspiration for some IRMs. 

We also would like to thank [CERT aDvens](https://github.com/cert-advens/IRM) for the collaborative work and the French translation.

Feel free to contact us if you identify a bug or an error in these IRMs.

This work is licensed under a [Creative Commons Attribution 3.0 Unported License](https://creativecommons.org/licenses/by/3.0/).
 
![Creative Commons Attribution 3.0 Unported License](http://i.creativecommons.org/l/by/3.0/88x31.png "Creative Commons Attribution 3.0 Unported License")
Incident Response Methodologies (CERT SG): README

Spanish version (Deprecated)
===============

The Spanish version is available [here](https://github.com/certsocietegenerale/IRM-deprecated/tree/master/ES).

These cheat sheets have been written in English and Russian, and translated into Spanish by Francisco Neira from the [OAS](https://github.com/phrancisco/IRMs-SP).
Incident Response Methodologies (CERT SG): README

Russian version (Deprecated)
===============

The Russian version is available [here](https://github.com/certsocietegenerale/IRM-deprecated/tree/master/RU).
Incident Response Plan Template: humans

/* TEAM */
Creator: Chris Hendricks
Site: https://www.counteractive.net
Twitter: @counteract_ive
Location: San Antonio, Texas, USA

Contributor: Katherine Henry
Twitter: @kathenry11
Location: Oklahoma City, Oklahoma, USA

Contributor: William Rowe
Location: Fredericksburg, Virginia, USA

/* THANKS */
Inspirations: Everyone involved in the prior art listed in the README

/* SITE */
Standards: markdown
Software: pandoc
Incident Response Plan Template: after

# Conduct an After Action Review (AAR)

1. Schedule an After Action Review (AAR) meeting within {{AAR_SLA}} and invite the attendees listed at {{AAR_ATTENDEES}}.  Always include the following:
    * The incident commander.
    * Service owners involved in the incident.
    * Key engineer(s)/responders involved in the incident.
1. Designate an AAR owner who will investigate the incident in advance of the meeting to prepare, looking into the incident process itself including reviewing notes and reports.

## Conduct the AAR Meeting

Document answers to the following key questions:

1. **What happened?** Create a timeline, supported with data or other artifacts. **Avoid blame. Find facts.**
1. **What was supposed to happen?**
    * Detail deviations from process, procedure, or best practice, including SME assessments.
    * Identify ways the incident could have been detected sooner, or responded to more effectively
1. **What were the root causes?** Find root cause to things that happened and to things that should have happened.
1. **How can we improve?** Capture action items _with assignees and due dates_.  Consider:
    * Stop: what should we stop doing?
    * Start: what should we start doing?
    * Continue: what should we keep doing?

## Communicate AAR Status and Results

The AAR owner, in coordination with the Internal Liaison, will  communicate the status of the AAR (see below)

### Status Descriptions

| Status | Description |
|-|-|
| **Draft** | AAR investigation is still ongoing |
| **In Review** | AAR investigation has been completed, and is ready to be reviewed during the AAR meeting. |
| **Reviewed** | AAR meeting is over and the content has been reviewed and agreed upon.<br>If there are additional "External Messages", the communications team will take action to prepare. |
| **Closed** | No further actions are needed on the AAR (outstanding issues are tracked in tickets).<br>If no "External Messages", skip straight to this once the meeting is over.<br>If there are additional "External Messages", communications team will update AAR Closed once sent. |

Communicate the results of the AAR internally and finalize the AAR documentation.
Incident Response Plan Template: role 0 all participants

## Role: All Participants

### Description

All participants in an incident response have the responsibility to help resolve the incident according to the incident response plan, under the authority of the Incident Commander.

### Duties

#### Exhibit Call Etiquette

* Join both the call and chat.
* Keep background noise to a minimum.
* Keep your microphone muted until you have something to say.
* Identify yourself when you join the call; State your name and role (_e.g._, "I am the SME for team x").
* Speak up and speak clearly.
* Be direct and factual.
* Keep conversations/discussions short and to the point.
* Bring any concerns to the Incident Commander (IC) on the call.
* Respect time constraints given by the Incident Commander.
* If you join only one channel (call or chat), do not actively participate, as it causes disjoined communication.
* **Use clear terminology, and avoid acronyms or abbreviations. Clarity and accuracy is more important than brevity.**

##### Reference: Common Voice Procedure

Standard radio [voice procedure](https://en.wikipedia.org/wiki/Voice_procedure#Words_in_voice_procedure) **is not required**, however you may hear certain terms (or need to use them yourself). Common phrases include:

* **Ack/Rog:** "I have received and understood"
* **Say Again:** "Repeat your last message"
* **Standby:** "Please wait a moment for the next response"
* **Wilco:** "Will comply"

**Do not** invent new abbreviations; favor being explicit over implicit.

#### Follow the Incident Commander

The Incident Commander (IC) is the leader of the incident response process.

* Follow instructions from the incident commander.
* Do not perform any actions unless the incident commander has told you to do so.
* The commander will typically poll for strong objections before tasking a large action. Raise objections if you have them.
* Once the commander has made a decision, follow that decision (even if you disagreed).
* Answer any questions the commander asks you in a clear and concise way.  Answering "I don't know" is acceptable. Do not guess.
* The commander may ask you to investigate something and get back to them in X minutes. Be ready with an answer within that time.  Asking for more time is acceptable, but provide the commander an estimate.

### Training

Read and understand the incident response plan, including the roles and playbooks.
Incident Response Plan Template: role 3 scribe

## Role: Scribe

### Description

A Scribe documents the timeline of an incident as it progresses, and makes sure all important decisions and data are captured for later review.  The Scribe should focus on the incident file, as well as follow-up items for later action.

### Duties

1. Ensure the incident call is being recorded.
1. Note in chat and in the file timelines: important data, events, and actions, as they happen. Specifically:
    * Key actions as they are taken
    * Status reports when one is provided by the IC
    * Any key call-outs either during the call or at the ending review
1. Update the chat with who the IC is, who the Deputy is, and that you're the scribe (if not already done).

Scribing is more art than science. The objective is to keep an accurate record of important events that occurred, Use your judgement and experience. But here are some general things you most definitely want to capture as scribe.

* The result of any polling decisions.
* Any followup items that are called out as "We should do this..", "Why didn't this?..", etc.

### Training

Read and understand the incident response plan, including the roles and playbooks.

#### Prerequisites

* Excellent verbal and written **communication skills**.
* Anyone can act as a scribe during an incident, and are chosen by the Incident Commander at the start of the call.
* Typically the Deputy will act as the Scribe

#### Training Process

* Read the incident response plan, including all roles and playbooks.
* _OPTIONAL:_ Parallel the actions of a scribe during an incident or exercise, and seek feedback from the actual Scribe and Incident Commander.
Incident Response Plan Template: index

# Roles

The following are the descriptions, duties, and training for each of the defined roles in an incident response.

`TODO: Customize roles, descriptions, duties, and training, if necessary.`

## Structure of Roles

* Command Team
  * [Incident Commander](#role-incident-commander-ic)
  * [Deputy Incident Commander](#role-deputy-incident-commander-deputy)
  * [Scribe](#role-scribe)
* Liaison Team
  * Internal [Liaison](#role-liaison)
  * External Liaison
* Operations Team
  * [Subject Matter Experts](#role-subject-matter-expert-sme) (SMEs) for Systems
  * SMEs for Teams/Business Units
  * SMEs for Executive Functions (_e.g._, Legal, HR, Finance)
During larger complex incidents, the role structure may be adjusted to account for the creation of sub-teams. Read about how we handle [complex incidents](/before/complex_incidents.md) for more information.

This is a **flexible structure**: every role will not be filled by a different person for every incident. For example, in a small incident the Deputy might act as the Scribe and Internal Liaison. The structure is flexible and scales based on the incident.

## Wartime vs. Peacetime

On incident response calls ("wartime"), a different organizational structure overrides normal operations ("peacetime"):

* The Incident Commander is in charge. No matter their rank during peacetime, they are now the highest ranked individual on the call, higher than the CEO.
* Primary responders (folks acting as primary on-call for a team/service) are the highest ranked individuals for that service.
* Decisions will be made by the IC after consideration of the information presented. Once that decision is made, it is final.
* Riskier decisions can be made by the IC than would normally be considered during peacetime.
* The IC may go against a consensus decision. If a poll is done, and 9/10 people agree but 1 disagrees. The IC may choose the disagreement option despite a majority vote.  Even if you disagree, the IC's decision is final. During the call is not the time to argue with them.
* The IC may use language or behave in a way you find rude. This is wartime, and they need to do whatever it takes to resolve the situation, so sometimes rudeness occurs. This is not personal, and something you should be prepared to experience if you've never been in a wartime situation before.
* You may be asked to leave the call by the IC, or you may even be forcibly kicked off a call. It is at the IC's discretion to do this if they feel you are not providing useful input. Again, this is not personal and you should remember that wartime is different than peacetime.
Incident Response Plan Template: role 2 deputy

## Role: Deputy Incident Commander (Deputy)

### Description

A Deputy Incident Commander (Deputy) is a direct support role for the Incident Commander (IC). The Deputy enables the IC to focus on the problem at hand, rather than worrying about documenting steps or monitoring timers. The deputy supports the IC and keeps them focused on the incident.  As a Deputy, you will be expected to take over command from the IC if they request it.

### Duties

1. Bring up issues to the Incident Commander that may otherwise not be addressed (keeping an eye on timers that have been started, circling back around to missed items from a roll call, etc).
1. Be a "hot standby" Incident Commander, should the primary need to either transition to a SME, or otherwise have to step away from the IC role.
1. Manage the incident call, and be prepared to remove people from the call if instructed by the Incident Commander.
1. Monitor the status of the incident, and notify the IC if/when the incident escalates in severity level.
1. Monitor timers:
    * track how long the incident has been running
    * notify the IC every X minutes so they can take actions (_e.g._, "IC, be advised the incident is now at the 10 minute mark.")
1. Monitor task deadlines (e.g., "IC, be advised the timer for [TEAM]'s investigation is up.")

### Training

* Read and understand the incident response plan, including the roles and playbooks.

#### Prerequisites

* Be trained as an [Incident Commander](#role-incident-commander-ic).