- User Since
- Sep 7 2017, 9:40 AM (101 w, 3 d)
Sun, Aug 11
@dkg First step toward the canonical OpenPGP certificate export: http://git.savannah.nongnu.org/cgit/libtmcg.git/commit/?id=75372cac01501ae427dec1ae18805449bf28d087
Sat, Aug 10
@wiktor-k Thanks for your interest.
Fri, Jul 19
IIUC, there is only a single recipient, but it has 256 SKESK packets, while only a single SKESK is valid and others are all dummy, right?
Jul 18 2019
Unfortunately, for my use case the corresponding SKESK packet number is not known when calling GnuPG.
Jul 17 2019
But that's exactly my use case in DOTS: an easily to create 'decryption puzzle' (including the hardness of iterated and salted S2K) for the serving party in order to make DoS harder. I don't see how public-key crypto can help here. Moreover, I would keep the user interaction as cheap as possible, i.e., copy'n'paste an ASCII-armored message and passwort to GnuPG without importing public keys etc.
@gniibe Thanks for explaining the background. Are there any ideas for fixing? (e.g. the decrypted content could be checked for a valid packet structure or at least for starting with a valid packet header)
Jul 12 2019
Jul 8 2019
then they are sorted by their binary content.
Jul 3 2019
Recently, I started a new project at savannah for developing free software and documentation in order to operate a Distributed OpenPGP Timestamping Service. Everyone is welcome to join.
Nov 15 2018
Nov 13 2018
The corresponding fix can be found here: https://github.com/smuellerDD/jitterentropy-library/commit/9048af7f06fc1488904f54852e0a2f8da45a4745
Please note that this issue in Jitterentropy has been already fixed by upstream: http://www.chronox.de/jent.html
Oct 30 2018
There is another argument for respecting the usage flags: it trims the admissible key space, if key ID in the PKESK packet is zero ('wild card') and thus all private keys have to be considered for decryption.
Sep 9 2018
By the attached test program I can confirm that the issue is solved.
Aug 30 2018
BTW: For TSA keys an additional key (usage) flag ("This key may be used for time-stamping") in RFC 4880bis would be nice. What do you think?
According to RFC 3628 there are two additional conditions to consider:
A timestamp or a time mark (which is an audit record kept in a secure audit trail from a trusted third party) applied to a digital signature value proves that the digital signature was created before the date included in the time-stamp or time mark.
Aug 27 2018
Attached is a timestamp signature created with the test key (alfa, alpha, alice) from tests/openpgp.
Aug 25 2018
DKGPG will contain programs to generate such signatures in its next release. Thus it would be nice, if those signatures can be verified by GnuPG as one of the most widespread OpenPGP implementations.
Aug 24 2018
Aug 20 2018
Jul 4 2018
What happens, if other bad packets beside PKT_USER_ID, PKT_ATTRIBUTE, PKT_OLD_COMMENT, and PKT_COMMENT are found?
Jun 24 2018
Jun 14 2018
I've made the parsing less strict in LibTMCG: https://github.com/HeikoStamer/libtmcg/commit/be7963b33cf8bace9d031074521acc4e89930d33
Mar 20 2018
Feb 24 2018
Jan 24 2018
Please note that Section 13.6 of RFC 4880 says:
Jan 7 2018
I have attached a small patch to show this two additional key flags with "--list-keys":
Nov 25 2017
After having a look at the code base I guess this behaviour is intentional.