- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 25 2019
APIs which need revise (where we use pid_t):
API which uses int for fd:
GnuPG common:
- gnupg_create_pipe, gnupg_create_outbound_pipe, gnupg_create_inbound_pipe
- gnupg_spawn_process_fd
gpgrt:
- gpgrt_make_pipe (not yet exposed to public API)
- gpgrt_spawn_process_fd (not yet exposed to public API)
HANDLE type casting to long is wrong (it results masking the value to 32-bit, which is not needed).
I fixed:
I see your point (I am also the one who implements reader/token). That's reasonable argument.
Thanks for your report, with helpful log.
Jul 24 2019
Jul 23 2019
Jul 22 2019
Backported.
I realized that it's a product of token. Then, I suggest that implementing time extension correctly, if some operation doesn't finish in BWT (block waiting time).
In general, if it requires more time, a reader can reply with time extension.
What's Trustica Cryptoucan?
In general, if it requires more time, a reader can reply with time extension.
FYI, we have "factory-reset" command in gpg --card-edit; It is not enough for a card to have admin locked state, but it requires normal user locked state, too.
Jul 20 2019
Yes: at least 255 times.
Jul 19 2019
Patch is pushed to master. Will be backported to 2.2.
It responds somehow, but the content has invalid data of (bChainParameter=0x04):
2019-07-05 09:36:41 scdaemon[71407] DBG: chan_17 -> S LOGIN-DATA aheinecke 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: PC_to_RDR_XfrBlock: 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: dwLength ..........: 9 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bSlot .............: 0 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bSeq ..............: 21 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bBWI ..............: 0x04 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: wLevelParameter ...: 0x0000 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: [0010] 00 40 05 00 CA 00 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: [0016] 6E 00 E1 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: RDR_to_PC_DataBlock: 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: dwLength ..........: 4 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bSlot .............: 0 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bSeq ..............: 21 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bStatus ...........: 0 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bChainParameter ...: 0x04 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: [0010] 00 82 00 82 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: PC_to_RDR_XfrBlock: 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: dwLength ..........: 9 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bSlot .............: 0 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bSeq ..............: 22 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bBWI ..............: 0x04 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: wLevelParameter ...: 0x0000 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: [0010] 00 40 05 00 CA 00 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: [0016] 6E 00 E1 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: RDR_to_PC_DataBlock: 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: dwLength ..........: 4 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bSlot .............: 0 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bSeq ..............: 22 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bStatus ...........: 0 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bChainParameter ...: 0x04 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: [0010] 00 82 00 82 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: PC_to_RDR_XfrBlock: 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: dwLength ..........: 9 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bSlot .............: 0 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bSeq ..............: 23 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bBWI ..............: 0x04 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: wLevelParameter ...: 0x0000 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: [0010] 00 40 05 00 CA 00 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: [0016] 6E 00 E1 2019-07-05 09:36:46 scdaemon[71407] DBG: ccid-driver: usb_bulk_read error: LIBUSB_ERROR_TIMEOUT 2019-07-05 09:36:46 scdaemon[71407] ccid_transceive failed: (0x1000a) 2019-07-05 09:36:46 scdaemon[71407] apdu_send_simple(1) failed: card I/O error
After the cancellation, the card reader seems being screwed up:
It is canceled:
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: RDR_to_PC_DataBlock: 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: dwLength ..........: 0 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bSlot .............: 0 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bSeq ..............: 19 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bStatus ...........: 64 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bError ............: 239 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: CCID command failed: PIN cancelled 2019-07-05 09:36:41 scdaemon[71407] DBG: dismiss pinpad entry prompt 2019-07-05 09:36:41 scdaemon[71407] DBG: chan_7 -> INQUIRE DISMISSPINPADPROMPT 2019-07-05 09:36:41 scdaemon[71407] DBG: chan_7 <- END 2019-07-05 09:36:41 scdaemon[71407] verify CHV2 failed: Invalid response 2019-07-05 09:36:41 scdaemon[71407] operation decipher result: Invalid response 2019-07-05 09:36:41 scdaemon[71407] app_decipher failed: Invalid response 2019-07-05 09:36:41 scdaemon[71407] DBG: chan_7 -> ERR 100663372 Invalid response <SCD>
Please note that key generation is takes time unusually longer from a viewpoint of card reader.
It is possible for a card reader to give up the execution of key generation command as timeout.
I am trying to reproduce your problem with my 3.3 card using my TTXS card reader.
Thank you. Merged.
Sorry, perhaps, I misunderstood how SKESK packets are generated in your application.
I was considering there were 256 recipients.
Jul 18 2019
If the use of GnuPG (current implementation) is a condition, I think that you could improve the generation of SKESK packets, so that no other passphrase can let gpg misunderstand as it may decrypt encrypted packet.
Please let us know what kind of key and how large, like RSA-4096 or ECC Brainpool.
For RSA 2048 or larger, yes, it takes too long.
Thanks.
Merged (with line break in the Makefile.am and formatting of commit message.
I mean, if all SKESK packets should be tried, we need some larger surgery of current implementation.
Is it possible for your application (DOTS), to specify the packet number for SKESKP, not trying all SKESK packets?
^-- with this change, we can decrypt the skesks.asc with --passphrase-repeat=169, and skesks2.asc with --passphrase-repeat=30
Jul 16 2019
It was rG07250279e7ec: * keyedit.c (keyedit_menu): Invisible alias "passwd" as "password". in 2004, which set default to rfc2440-text behavior.
And in 2007, the commit rGb550330067b6: * gpg.c (main): Disable --rfc2440-text and --force-v3-sigs by default. changed the default to no-rfc2440-text.
Thanks, fixed in master.
Current situation of *.pc: static linking is not supported (yet).
It has never supported, actually, by *-config.
While I understand incorrectness, the risk in practice is not that high. So, I put this as "normal" priority.
In the current implementation of GnuPG, multiple packets of Symmetric-Key Encrypted Session Key Packet are not handled very well.
Pushed the change to master as well as 2.2 branch.
Jul 15 2019
Jul 12 2019
About importing, there are two other works: repairing and trustdb update. We can figure out the difference by the --import-options of no-repair-keys and fast-import (to skip those works).
I think that both can be O(N^2) for number of signatures.
I disabled the dependency rules for the figures (it's only enabled for maintainers).
Fixed.
If I were testing more, I would generate many (say, 1000, or more, for example) encrypted message by the tool (IBM Encryption Facility), to examine by GnuPG and figure out some patterns of failure.
Jul 11 2019
While I only observed the output of --list-packet, what I see are:
With NTBTLS, it seems it works correctly.
Which SSH client are you using?
gpg-agent side is fixed to relax the error handling.
For the particular problem of --list-key with pubring.gpg, I think we can say it's fixed.
@werner : Yes, the way to go is having something like a server for keys; It can remove all unnecessary search/lookup all together.
Jul 10 2019
I pushed my change as: rT7b2c4d9dd50b: Support GCM.
Please test.
I pushed the fix. Thanks for your cooperation.
Thanks for further testing.
I realized that it's not the left border drawing problem in fact, but the newline should be between the description and passphrase line.
I'm going to fix this.
Err... my repo for 2.2 was a week old. Now, I updated, and confirmed it's there.
Thanks having the support!