DEV Community: chiefbiiko

falcon-cli 4 post-quantum file sigs

chiefbiiko — Sat, 02 Oct 2021 06:37:51 +0000

Post-quantum cryptography is being developed, benchmarked, tested, discussed, and elaborated... Let me join in on that with a little practical software piece. falcon-cli is a CLI tool to sign and verify files with the post-quantum signature scheme FALCON, a round 3 finalist for digital signature algorithms in NIST's post-quantum cryptography standardization competition.

The tool supports keygen, file sign and verify ops, as such it is complete and ready for common file signature use cases. Imagine - now you can sign your Github Releases with (probably) post-quantum safe signatures and chill (4ever)...

Usage should be straightforward when glimpsin' over the README. The default key location shouldn't be surprisin' as well: ~/.falcon-cli/(public|secret).key. Also, if explicit input or output files are omitted, the tool falls back to stdin and stdout for IO.

In case of any issues get at me on GitHub.

cors with apigw

chiefbiiko — Mon, 21 Dec 2020 08:02:48 +0000

cors with apigw

🌐🔗🌒🐙

lets assume a freshly mounted apigw with a resource /pitbulls having two endpoints serving and accepting json:

GET /pitbulls

POST /pitbulls

once you start hitting these from a browser they need to have cors enabled..

determining cors request types

there are two types of cors requests: simple and non-simple - refer to these AWS docs MDN docs 4 specifics.

a simple requests has the following characteristics:

GET, HEAD, or POST
if POST the request must include an origin header
request payload content type is text/plain, multipart/form-data, or application/x-www-form-urlencoded
no custom headers

steps 2 enable cors

4 simple requests

scenario: GET /pitbulls

the backend response must include an Access-Control-Allow-Origin header granting access to the request's origin domain. Note that one should specify protocol, domain, and port when defining the origin.

backend response to a simple cors request

return {
  statusCode: 200,
  headers: {
    "access-control-allow-origin": "https://your.domain:443",
    "content-type": "application/json"
  },
  body: '[{"name":"dogo"}]'
}

4 non-simple requests

scenario: POST /pitbulls with request payload content-type: application/json

our pitbulls resource needs to expose an OPTIONS method that responds to cors preflight requests with the following cors headers: Access-Control-Allow-Methods Access-Control-Allow-Headers Access-Control-Allow-Origin

cors options method snippet in cloudformation

CorsMethod:
  Type: AWS::ApiGateway::Method
  Properties:
    AuthorizationType: NONE
    RestApiId: !Ref RestApi
    ResourceId: !Ref PitbullsResource
    HttpMethod: OPTIONS
    Integration:
      Type: MOCK
      IntegrationResponses:
        - StatusCode: 200
          ResponseParameters:
            method.response.header.Access-Control-Allow-Headers: "'content-type'"
            method.response.header.Access-Control-Allow-Methods: "'OPTIONS,GET,POST'"
            method.response.header.Access-Control-Allow-Origin: !If
              - IsProd
              - "'https://your.domain:443'"
              - "'*'"
          ResponseTemplates:
            application/json: ''
      PassthroughBehavior: WHEN_NO_MATCH
      RequestTemplates:
        'application/json': '{"statusCode":200}'
    MethodResponses:
      - StatusCode: 200
        ResponseModels:
          application/json: Empty
        ResponseParameters:
          method.response.header.Access-Control-Allow-Headers: False
          method.response.header.Access-Control-Allow-Methods: False
          method.response.header.Access-Control-Allow-Origin: False

Additionally, the backend, lambdas, ec2s or whatever, need to also respond with the three cors headers listed above.

backend responding to a non-simple cors request with mandated headers

return {
  statusCode: 201,
  headers: {
    "access-control-allow-headers": "content-type",
    "access-control-allow-methods": "OPTIONS,POST",
    "access-control-allow-origin": "https://your.domain:443",
  },
}

🐙🌐🔗🌒 ~ AWS API Gateway CORS

lambda-wasmtime - Running WebAssembly on AWS Lambda

chiefbiiko — Mon, 18 Nov 2019 05:55:16 +0000

With lambda-wasmtime we have a wasmtime-powered custom AWS Lambda runtime for running WebAssembly, including futuristic stuff like WASI (WebAssembly System Interface) and WAIT (WebAssembly Interface Types).

To run in the AWS Lambda execution environment we need to build a WebAssembly module that exports a function capable of accepting and returning JSON strings. The remainder of this post demonstrates just that.

Building a WebAssembly Lambda

Make sure to have cargo-wasi installed: cargo install cargo-wasi

Setup a new project: cargo new <project_name> --lib

Craft Cargo.toml:

specify the crate type as cdylib to make this a C-ish shared library
include a recent wasm-bindgen (tested with 0.2.54)

[lib]
crate-type = ["cdylib"]

[dependencies]
wasm-bindgen = "0.2.54"

Define a handler in src/lib.rs and #[wasm_bindgen] it:

use wasm_bindgen::prelude::wasm_bindgen;

#[wasm_bindgen]
pub fn handler(event: &str, context: &str) -> String {
    // lambda-wasmtime passes the event and context as JSON
    // context looks like: { function_arn, deadline_ms, request_id, trace_id }
    event.to_string()
}

Note that you can name your handler whatever you want. The lambda-wasmtime runtime determines the actual handler name from the environment variable _HANDLER which is user-defined in AWS Lambda.

Build the .wasm binary: cargo wasi build --release

For now, when using wasm-bindgen --release mode is required to build binaries with interface types ~strings

Zipup a lambda bundle: zip -j <project>/lambda.zip <project>/target/wasm32-wasi/release/<project_name>.wasm

Deploy the lambda bundle on AWS with the lambda-wasmtime runtime layer - get its latest release from here

If your handler performs non-trivial computations you probably need to provision the lambda with extra memory. Also note that currently all of this is in MVP state and experimental.