Re: SSL attack scenario
On Tue, May 19, 2009 at 10:53:05AM +0200, João Távora wrote: Given a NDA forbids me from giving you more details let me give you an analogy with postal services: I assume you know of postal services where you can get a delivery receipt. you can get a receipt that the recipient was notified, if the postman gets shot along the way, the postal service will send more postman. If they run out of postmen I get a receipt stating the delivery was impossible. Analogies always fail :-) A normal letter is UDP: you don't know if it even arrives. A letter with delivery receipt (registered mail?) is like TCP: you know the letter has arrived, but you don't know it's been read. The equivalent of application acknowledgment would be the *letter* saying to the person once you read this, return the attached form. Then you need the application has read the message and done something about it. Then again, you can probably twist the analogy in a totally different way to say something even different. Bottom line is, each layer of a network is responsible for its own stuff. Y. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.0 beta 1 released
On Thu, Apr 02, 2009 at 08:01:48AM -0500, Michael S. Zick wrote: I realize that progress in the security field is slow - but will this new release support rfc1149? http://tools.ietf.org/html/rfc1149 That's a hardware layer, below IP. SSL is well above that, over TCP. If your operating system supports rfc1149, you should be able to use OpenSSL on it transparently (there is a patch for Linux here: http://www.blug.linux.no/rfc1149/). That was published back in '90 - it should be well vetted by now. Vetted? Does that consist in vaccination of the transport layer against the flu? Y. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Wider fallout from Debian issue?
On Wed, May 28, 2008 at 07:55:35PM +1200, Deane Sloan wrote: Finally - how real is this concern? What is the probability that say a 2048bit generated key could fall into the 32,767 keys in the metasploit SSH example on unaffected systems? 32,768 = 2^15 number of 2048 bit keys: 2^2048 Probability that a proper key falls in the space of the bad debian keys: 2^15 / 2^2048 = 1 / 2^2033. That's a lot of zeros before the first non-zero digit. Y. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: public key in the binary
On Wed, Oct 03, 2007 at 11:11:26AM -0500, Md Lazreg wrote: What problem does preventing the user from fielding a modified application solve? It solves the problem of preventing the user from running my application in a mode they did not pay for. If your target is PC software, then using dongles is probably the right way to go: the dongle designers are supposed to have thought of the problem in depth. For embedded targets, a company I worked at previously ultimately relied on scrambling the mode with the MAC address of the device in some obscure way and calling that 'the key', which would be computed in-house and given to the customers. Not very secure at all, but like said by Victor, it's probably enough to stop companies (and individuals wouldn't buy that product anyway). Cheers, Y. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL_peek vs. SSL_pending...
On Wed, Aug 29, 2007 at 08:07:04AM -0700, David Schwartz wrote: Yes, and additionally, there may be implementations supporting a select function but at the same time not even conforming the standard, I think such `TCP stacks' exist. BTW, which standard would it be, `4.4BSD'? I'm talking about The Single Unix Specification or The Open Group Base Specification. http://www.opengroup.org/onlinepubs/009695399/functions/FD_SET.html This is reasonably clear that 'select' reports current status, just as functions like 'stat' do. They provide no more of a future guarantee than functions like 'stat' do. Actually, this page says: A descriptor shall be considered ready for reading when a call to an input function with O_NONBLOCK clear would not block, whether or not the function would transfer data successfully. Is that not to say that if select() says it's ready to read, I'm guaranteed my next read() won't block? I notice the 'would not block' instead of 'will not block'. That makes me uneasy. Y. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL_peek vs. SSL_pending...
On Sat, Aug 25, 2007 at 12:47:57AM -0700, David Schwartz wrote: Yes? If so, the above paragraph or something similar should be documented somewhere important (e.g. the manpages). That's one way to put what I'm saying. I agree it needs to be repeated more often, that's one of the reasons I repeat it as often as I can. I'm afraid it's worse than just the man pages. After thinking for a fleeting moment that what you were saying made no sense, then thinking some more and thinking it did make sense, I went back to my standard bible Advanced Progamming in the Unix environment (Stevens Rago), which actually explicitely states (select and pselect functions, p475): With [select's] return information, we can call the appropriate I/O function (usually read or write) and know that the function won't block. I guess this should read call the I/O function and know it wouldn't have blocked if we'd called it instead of calling select. Not every day I learn something new. Though I'm slightly horrified because my code base is extensive and I do quite a bit of socket programming...and I've been doing it wrong for about 7 years. This is apparently going to be a LONG weekend. If even the reference litterature gets it wrong... Y. -- who'll be writing better code from now on __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
relationship between cipher suites and encoders
Hi, I'm trying to work out the relationship between a cipher suite, and the encrypters available in OpenSSL. For example, in OpenSSL 0.9.8e I see there is blowfish encryption available (in `openssl enc`), yet none of the bf variants appear in the cipher suite list (`openssl ciphers`). So, where does the cipher suite list come from, and how would one proceed if one wanted a cipher that's not already available in that list (specifically, I'm interested in cfb and ofb modes)? Cheers, Y. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
