Skip to content

Tracking: review and release chained block ORE (ore v2) so text can use block ORE #95

Open

Description

@coderdan

Background

Block ORE (Lewi–Wu) is the order scheme EQL stores in its _ord_ore and
_search_ore column types. ore-rs implements it for fixed-width values only.

Problem

Block ORE can't encrypt text in a general way. cipherstash-client works around
this by packing text into at most six 64-bit blocks, which is ASCII-only and
ignores everything after about 76 characters. A variable-length chained-prefix
scheme exists only as draft PRs #78 to #83, integrated in #90, last updated in
June 2026. Until it ships, Stack Encrypt can't produce TextOrdOre or
TextSearchOre (cipherstash/stack#1132).

Proposal

  1. Bring the stack to review, starting with ORE v2 (1/n): compatibility vectors + bench baselines #78, and decide on the open gates:
    Unify v2 ORE on a single-key API (split the OreCipher trait) #89 (a single-key API for v2) and SIMD AVX2 path is unverified pre-merge (no x86 CI on the stack) #87 (the AVX2 path has no x86 CI).
  2. Release ore-rs with the chained scheme.
  3. vitaminc-ore then adds block ORE for text in a minor release.

This is not on the critical path for vitaminc 0.6.0, which ships without block
ORE for text and records the gap in its conformance exceptions list.

Status (2026-10-12)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or requestrustPull requests that update rust code

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions