More or less. You need to create a policy with ~80 attributes to produces the bug and call encrypt/keygen, respectively. Unclear if this is a parser issue or scheme issue. Happens with AC17/BSW schemes (all).

I've been using this library for part of my Ph.D. research. it has proven very useful so far, but I was wondering about the AES cipher used underneath.

I've seen that rabe calls aes from aes-0.7.0. This crate only offers AES or AES-CTR. Seemed weird to me, and I have checked the newest version of aes crate and developers comment how:

This crate implements only the low-level block cipher function, and is intended for use for implementing higher-level constructions only. It is NOT intended for direct use in applications.

So now I'm wondering what mode of AES does Rabe use. Or whether at some point in the code you build AES-CBC or AES-GCM.

In case Rabe is using pure AES, since this is not recommended, are you planning on implementing AEADs?

BTW thanks for all the hard work 😄

Hello,

The YCT14 scheme was broken in [1] and a 'fixed' version was again broken in [2]. We have demonstrated how the attack can be implemented in practice in https://www.blackhat.com/eu-21/briefings/schedule/index.html#practical-attacks-against-attribute-based-encryption-25058.

[1] https://ieeexplore.ieee.org/document/8651482 [2] https://ieeexplore.ieee.org/document/9291064

The CLI tools do not work anymore for BSW and AC17 C/KP-ABE. Apparently, the added schemes cause this.

The problem: https://github.com/Fraunhofer-AISEC/rabe/blob/master/src/main.rs#L1228 This line fails with:

  0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:197
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:211
   4: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:474
   5: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:381
   6: std::panicking::begin_panic_fmt
             at src/libstd/panicking.rs:336
   7: rabe::main::read_file
             at src/main.rs:1574
   8: rabe::main::run_encrypt
             at src/main.rs:1228
   9: rabe::main::run
             at src/main.rs:406
  10: rabe::main
             at src/main.rs:393
  11: std::rt::lang_start::{{closure}}
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libstd/rt.rs:64
  12: std::panicking::try::do_call
             at src/libstd/rt.rs:49
             at src/libstd/panicking.rs:293
  13: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:85
  14: std::rt::lang_start_internal
             at src/libstd/panicking.rs:272
             at src/libstd/panic.rs:394
             at src/libstd/rt.rs:48
  15: std::rt::lang_start
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libstd/rt.rs:64
  16: main
  17: __libc_start_main
  18: _start

Reason:

https://github.com/Fraunhofer-AISEC/rabe/blob/master/src/main.rs#L329

The wrong variable is assigned.

This project depends on georgbramm/bn which is a fork of zcash-hackworks/bn. The former is not available as a crate, the latter seems to be not maintained anymore (the last PR is open for >2yrs).

Publishing to crates.io requires all dependencies to be available on crate.io as well. So, there are only two options:

1. Create a PR and convince the maintainers of zcash-hackworks to accept and publish it as a version bn:0.4.4

2. Publish georgbramm/bn as a whole new crate, say under the name bn-serde.

3. Include georgbramm/bn as a submodule into this project and bundle it into the published crate

This PR does (3).

(1) would obviously be favorable, but the chances of convincing the zcash authors to accept a major breaking PR in the near future are low.

(2) is irreversible and may lead to further confusion

(3) is not elegant, but it can easily be reverted in case an updated version of bn is published in the future

Hi. My name is Humberto. I am studying about ABE, and I get rabe-console to test it. But i don't take success in file encrypt e decryption. For example:

Start with:

$ rabe --s AC17CP setup $ rabe --s AC17CP keygen --a 'A B'

In the encryption example 1:

rabe --s AC17CP encrypt pk.key 'B' teste.doc

It finish at error:

error: The following required arguments were not provided:

USAGE: rabe encrypt [ARGS]

And other example, 2:

rabe encrypt pk.key "B" ./teste.doc

error: The following required arguments were not provided:

USAGE: rabe --s encrypt [ARGS]