Smart-card daemon and PKCS#11
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 After several independent queries about my PKCS#11 patch to gpg 1.4, I've decided to start an independent project and do the thing properly instead of keeping the patch up-to-date. The project aims to replace the scdaemon component of GnuPG 2 with another (named p11scd) which is able to work with read-only PKCS#11 cards. The project is hosted at: https://dev.interhost.no/p11scd/ The wiki is closed for public editing, but you may read it and access the subversion repository. If you have any comments/questions about the currently stated design-decisions, please send them to my email. I might set up a google mailing list in the future if enough people become interested. Please note that I'm doing this in my free time (which is not abundant), so I give no time frame when the project is going to be finished. If you want to participate in the project, please also drop me a mail. Rationale: This will enable the use of many other smart-card types with GnuPG than is currently possible. (One frequently asked for was Schlumberger - - now Axalto - Cryptoflex). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEgqASUIHQih3H6ZQRAzbtAKCw/U61XkMYvxDxM7vUZnKfjsFcDgCePt2X 3Ljp3V3jN9hx7v1U0bmWXtg= =EGV8 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [lists] re: Signing vs. encrypting was: Cipher v public key
On Thu, 01 Jun 2006 11:33:14 -0400 [EMAIL PROTECTED] wrote: While I prefer gnupg to pgp myself, I did just happen to see a reference to pgp command line today the cost is *astronomical* have played around with it when it was released as a free command line pgp 8.5 beta [snipped] AFAIK this is the latest PGP command line version available - except for server based systems, which is why the cost is *astronomical*. When Network Associates sold the rights to PGP to PGP Corporation, they kept the rights to the command line version, and unless things have changed this is why PGP Corporation don't offer it. But why bother when there is GPG? -- Graham ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GPG Implementation of Symmetric Operations, and To-Self Encryption
I have a couple of questions about GPG that fall in the range above pure mathematical equations but below You use this option. Mostly they're of the form This is how I understand it now, can you confirm that I've got it? Firstly, in pure RSA/ElGamal etc, there is no passphrase U - there's numbers p,q,g,a,b, etc. The way I understand it: Your secret key is encrypted using your passphrase. Your passphrase essentially acts as a symmetric key, one never stored anywhere except your head. Am I correct in the belief that this is how it works? I imagine it's some type of hashing or somesuch. If you don't want to give all the details of transformation from passphrase to key, that's okay, just want to make sure I understand it. Secondly, Using the option --symmetric creates a .gpg file and prompts you for a passphrase that the symmetric key is based on. Decrypting a Symmetric-ly Encrypted file is done by generic --decrypt option, and the header, non-encrypted part of the file says Hey this is symmetric, prompt for a passphrase Thirdly, GPG is based upon a hybrid system entirely. The data of any file is ALWAYS encrypted symmetrically, and a symmetric key is made for each encryption use. The symmetric key used is then encrypted with the public key of the recipient and the whole thing is bundled together. If I'm encypting something already zipped or compressed in any other method, I should use -z 0 because trying to compress it further isn't likely to do much, and it will slow down the processing - right? RSA ElGamal use keys around 1024-2048 usually. EC uses 160-224 bit keys, but is based on mostly different math (it may be equivalent at some level, but I'm neither aware nor able to understand anythig beyond yes or no on that topic). AES uses 256 bit. It's not allowed to go over 256 bit. This is because it's an entirely different area of cryptography? Block Ciphers as opposed to integer factorization, discrete logs, or curvature? And comparing key lengths between the three areas (IF/DS, EC, Block) without any normalization is like comparing the engine in a semi to one in a sedan without considering the weights of the vehicles - They both enable the vehicle to go 80 (encrypted to some rigor) but the semi needs a much larger one because the truck weighs more (easier to test factors than undo block ciphers). Right? Some questions I couldn't find answers too online: RSA, ElGamal - I've always learned them as Asymmetric Ciphers - Public Key/Private Key. What algorithm does GPG use for the symmetric side of things? What's the size of the key? (the size of the key chosen for the Keypair?) For encryption of documents to myself, I can: - Use Symmetric Encryption with a passphrase of my choosing. But a passphrase seems weaker than a full blown key. - Use the --encrypt-to-self or --recipient options. I encrypt the Document using my public key so only my Private key can open it. - Is there an option to have a Symmetric Key, that behaves like both a public and a private key? Obviously you'd have to not publish your the key, but apart from that? It may be protected by a passphrase, it may not and rely upon the user to control Key access (an interesting implementation would be a very large symmetric key, that is stored on a removable media or encrypted partition that is inserted/mounted whenever access is needed, and not allowed to be stored anywhere but Volatile Memory) - Any other advised methods? --throw-keyid --encrypt-to-self will produce a file that, considering all available information available in the file, is known ONLY to be encrypted by GPG X.Y.Z with the private key of some individual. But may only be decrypted by myself (because it's encrypted to myself). Right? What would happen if I tried --symmetric --throw-keyid ? Does ElGamal double the size of the encrypted document if used without encryption? Thanks for any and all answers. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG Implementation of Symmetric Operations, and To-Self Encryption
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 06/04/2006 10:36 PM, [EMAIL PROTECTED] wrote: Firstly, in pure RSA/ElGamal etc, there is no passphrase U - there's numbers p,q,g,a,b, etc. Only when you encrypt. The way I understand it: Your secret key is encrypted using your passphrase. Your passphrase essentially acts as a symmetric key, one never stored anywhere except your head. Am I correct in the belief that this is how it works? I imagine it's some type of hashing or somesuch. If you don't want to give all the details of transformation from passphrase to key, that's okay, just want to make sure I understand it. Almost correct. Secondly, Using the option --symmetric creates a .gpg file and prompts you for a passphrase that the symmetric key is based on. Decrypting a Symmetric-ly Encrypted file is done by generic --decrypt option, and the header, non-encrypted part of the file says Hey this is symmetric, prompt for a passphrase Right. Thirdly, GPG is based upon a hybrid system entirely. Only when you use public key encryption. The data of any file is ALWAYS encrypted symmetrically, and a symmetric key is made for each encryption use. It is called session key. The symmetric key used is then encrypted with the public key of the recipient and the whole thing is bundled together. OK. If I'm encypting something already zipped or compressed in any other method, I should use -z 0 because trying to compress it further isn't likely to do much, and it will slow down the processing - right? Gnupg is aware of different compression algos(bzip2, zlib, zip) and when encounters such a compressed file disable compression automatically. RSA ElGamal use keys around 1024-2048 usually. 1024 RSA/ElGamal is considered semi-weak. EC uses 160-224 bit keys, but is based on mostly different math (it may be equivalent at some level, but I'm neither aware nor able to understand anythig beyond yes or no on that topic). AES uses 256 bit. It's not allowed to go over 256 bit. This is because it's an entirely different area of cryptography? This is because AES doesn't allow this. Stop. Block Ciphers as opposed to integer factorization, discrete logs, or curvature? And comparing key lengths between the three areas (IF/DS, EC, Block) without any normalization You could read NIST Special Pubblication 800-57 section 5.6.1 about this issue. Some questions I couldn't find answers too online: RSA, ElGamal - I've always learned them as Asymmetric Ciphers - Public Key/Private Key. What algorithm does GPG use for the symmetric side of things? What's the size of the key? (the size of the key chosen for the Keypair?) gpg --versions shows supported algorithms. Many symmetric ciphers allow only a fixed length key by desing(IDEA, CAST5, 3DES); others(AES, TWOFISH, BLOWFISH) can be used with different key sizes, but only AES is used in such a way in OpenPGP. For encryption of documents to myself, I can: - Use Symmetric Encryption with a passphrase of my choosing. But a passphrase seems weaker than a full blown key. You still use a passphrase to protect the secret part of your keyring, this is the weak link of most cryptosystems. - Is there an option to have a Symmetric Key, that behaves like both a public and a private key? Obviously you'd have to not publish your the key, but apart from that? If you must not publish it, what makes it a public key? Hmmm, some bells start ringing in my head. Is this a homework assignment? --throw-keyid --encrypt-to-self will produce a file that, considering all available information available in the file, is known ONLY to be encrypted by GPG X.Y.Z with the private key of some individual. But may only be decrypted by myself (because it's encrypted to myself). Right? This is wrong twice. Guess why. What would happen if I tried --symmetric --throw-keyid ? Try yourself. Does ElGamal double the size of the encrypted document if used without encryption? This is DEFINITELY a homework assignment! Ever heard of Google? It is the holy saint of high school students. - -- Q.E.D. ICQ UIN: 301825501 OpenPGP key ID: 0x58D14EB3 Key fingerprint: 00B9 3E17 630F F2A7 FF96 DA6B AEE0 EC27 58D1 4EB3 Check fingerprints before trusting a key! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEg1oSH+Dh0Dl5XacRA8KkAJ94z914Z6TMrpZzDX1/0P4V5dUnYgCghUPf BJkf7JeMVOQVfoGJTrjMSuY= =ajKl -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG Implementation of Symmetric Operations, and To-Self Encryption
Hey! Too much things to answer... I will only respond some that I can know the answer, sorry. A Diumenge 04 Juny 2006 22:36, [EMAIL PROTECTED] va escriure: (...) Thirdly, GPG is based upon a hybrid system entirely. The data of any file is ALWAYS encrypted symmetrically, and a symmetric key is made for each encryption use. The symmetric key used is then encrypted with the public key of the recipient and the whole thing is bundled together. Think, for example that you want to send 100MB of information to 10 people. With in a pure asymmetric system yo will encrypt it one by one and then send at less 1GB (possible more). Using a hybric scheme (not less secure) you will send 100MB symmetrically encrypted and a little more of 10k where you have the symmetric key encrypted one by one. RSA ElGamal use keys around 1024-2048 usually. EC uses 160-224 bit keys, but is based on mostly different math (it may be equivalent at some level, but I'm neither aware nor able to understand anythig beyond yes or no on that topic). AES uses 256 bit. It's not allowed to go over 256 bit. This is because it's an entirely different area of cryptography? Block Ciphers as opposed to integer factorization, discrete logs, or curvature? And comparing key lengths between the three areas (IF/DS, EC, Block) without any normalization is like comparing the engine in a semi to one in a sedan without considering the weights of the vehicles - They both enable the vehicle to go 80 (encrypted to some rigor) but the semi needs a much larger one because the truck weighs more (easier to test factors than undo block ciphers). Right? To stablish the equivalence of security between different algorithm, also from different nature (like compare symmetric/asymmetric) we could use a formula that relates how many basic operations are needed to broke it, with how many basic operations the computer could do per second. Then you have one very much optimistic time. If some one find a new atack to one cryptosystem, this equivalences will change. (...) Sorry for the partial answer. Some one else could answer you better than I. /Sergi. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
