search

engyon / enprot

enprot command line tool for Engyon
1 stars 1 forks source link

Incorrect recursive processing #15

Closed dewyatt closed 4 years ago

dewyatt commented 4 years ago

For example:

enprot -s Agent_007 sample/test.ept
enprot -s GEHEIM sample/test.ept
enprot -f Agent_007,GEHEIM sample/test.ept

Will produce:

hello, this is a test file
// <( BEGIN GEHEIM )>
Secret line 1
Secret line 2
// <( STORED Agent_007 d094e230861eb0ab43b895b8ecdeeb9e3a7e4a88239341a81da832ac181feaab )>
// <( END GEHEIM )>
// <( BEGIN Agent_007 )>
Super secret line 3
// <( END Agent_007 )>

So despite the fact that we have requested a fetch for Agent_007, one (nested) message remains stored.

Similarly for encryption:

enprot -e Agent_007 -k Agent_007=password sample/test.ept
enprot -e GEHEIM -k GEHEIM=password sample/test.ept
enprot -d Agent_007,GEHEIM -k Agent_007=password,GEHEIM=password sample/test.ept

Will produce:

hello, this is a test file
// <( BEGIN GEHEIM )>
Secret line 1
Secret line 2
// <( ENCRYPTED Agent_007 )>
// <( DATA Huv6NIPclEG9s4tNOPEzQtgK+LW9pqYSA6Az )>
// <( END Agent_007 )>
// <( END GEHEIM )>
// <( BEGIN Agent_007 )>
Super secret line 3
// <( END Agent_007 )>

So to fully decrypt the above, for example, you would have to run the decryption command twice because an Agent_007 message is nested inside a GEHEIM message.

It only gets worse the deeper the nesting of course, so we should probably remove this burden from the user.

ronaldtse commented 4 years ago

Absolutely agree. We should allow the user to process the nesting - either exhausting all (allowed) levels or to a specified nesting level.

dewyatt commented 4 years ago

In addition to the above there's also this case:

$ cargo run -- -e GEHEIM,Agent_007 -k Agent_007=password,GEHEIM=pass sample/test.ept -o - | cargo run -- -d GEHEIM -k GEHEIM=pass
hello, this is a test file
// <( BEGIN GEHEIM )>
Secret line 1
Secret line 2
// <( BEGIN Agent_007 )>
James Bond
// <( END Agent_007 )>
// <( END GEHEIM )>
// <( ENCRYPTED Agent_007 pbkdf:$argon2$m=94208,p=1,t=1$0gLnFQvMS5FBfSZmxQHwXA== )>
// <( DATA lK3G2u0hvFLT9Npml19YQfdQkNoso79qg6RjtryjwHEpD0Dq )>
// <( END Agent_007 )>

Here the user requested encryption for both the GEHEIM and Agent_007 sections, but the Agent_007 nested inside GEHEIM was never actually encrypted (it was encrypted with GEHEIM's pass). So I think that behavior should be considered a bug.

I believe I have this fixed but I also need to update some tests.

dewyatt commented 4 years ago

https://github.com/riboseinc/enprot/pull/52