Re: [openssl-users] [THREAD CLOSED]
> On Apr 5, 2016, at 12:52 AM, Jakob Bohm wrote: > > Shut up troll, I was asking Victor what he meant, not > what you were guessing, and since this thread was > supposed to be closed, I wrote you directly. > > And if you are actually Victor, you are hiding it > pretty well. I am Victor, and I strongly object to this tone. When you're angry, do not vent on public lists, just walk away from the thread... [THREAD CLOSED] should not have been ignored many messages earlier. I am asking the list the list administrators that anyone posting new messages on this thread should be unsubscribed regardless of any plausible merit in the content. Over and out. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [THREAD CLOSED]
On 05/04/2016 04:21, PGNet Dev wrote: On 04/04/2016 07:08 PM, Jakob Bohm wrote: On 05/04/2016 02:57, PGNet Dev wrote: Sorry to post this here, but you failed to provide any address of said SPAM-L, nor yourself. Try again. http://bfy.tw/565B Troll! I didn't ask what things in the entire world were historically named "SPAM-L" (first two Google results are messages that a list by that name was shut down in 2009, third is a page announcing a new generic mailing list unrelated to discussing things with the OpenSSL list administrators). I was asking where Victor wanted the discussion to be moved, since he gave a vague answer "SPAM-L" (which could refer to almost any spam discussion list) and didn't provide an address where those in the thread could ask him directly. And using an URL shortener to point to another URL shortener (which actually hides the final Google page with a non-removable popup) is spammy behavior. Wow, you're special. Do not email me directly/offlist again. Shut up troll, I was asking Victor what he meant, not what you were guessing, and since this thread was supposed to be closed, I wrote you directly. And if you are actually Victor, you are hiding it pretty well. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Openssl-fips object module static library build with /MD option
I have a question on compiling Openssl-fips object module as 64 bit static library in win 8.1. I am using following versions of source and compile instruction. openssl-fips-2.0.12 1. cd openssl-fips-2.0.12 2. SET FIPSDIR=C:\tools\fips\opensslfips 3. ms\do_fips no-asm This turns out the build to be successful,however noticed it uses a compilation arg /MD . That turns out to be issue when I link this lib to my application. openssl-1.0.1p 1. cd openssl-1.0.1p 2. perl Configure VC-WIN64A fips --with-fipsdir=C:\tools\fips\opensslfips --prefix=C:\tools\fips\opensslBuild 3. ms\do_win64A Here I noticed the ms\nt.mak contains /MD too. As I used fips option to configure. 4. nmake -f ms\nt.mak Compiles OK, but with /MD option. My application requirement is to generate all these static lib with /MT option. How I can do that. The existing fips-object module User Guide 2.0 does not help in this regard. Would appreciate an early reply in this subject. Thanks GS -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] CMS with Symmetric key
> On Apr 4, 2016, at 11:34 PM, Salz, Rich wrote: > >> I'm trying to use the CMS operations in libcrypto but with a symmetric key >> encryption key instead of x509. > > We don't support this. It looks like we do. See crypto/cms/cms_pwri.c and the undocumented "-pwri_password" option of the cms(1) command. Documentation would of course be great... -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] CMS with Symmetric key
> I'm trying to use the CMS operations in libcrypto but with a symmetric key > encryption key instead of x509. We don't support this. -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [THREAD CLOSED]
On 04/04/2016 07:08 PM, Jakob Bohm wrote: On 05/04/2016 02:57, PGNet Dev wrote: Sorry to post this here, but you failed to provide any address of said SPAM-L, nor yourself. Try again. http://bfy.tw/565B Troll! I didn't ask what things in the entire world were historically named "SPAM-L" (first two Google results are messages that a list by that name was shut down in 2009, third is a page announcing a new generic mailing list unrelated to discussing things with the OpenSSL list administrators). I was asking where Victor wanted the discussion to be moved, since he gave a vague answer "SPAM-L" (which could refer to almost any spam discussion list) and didn't provide an address where those in the thread could ask him directly. And using an URL shortener to point to another URL shortener (which actually hides the final Google page with a non-removable popup) is spammy behavior. Wow, you're special. Do not email me directly/offlist again. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [THREAD CLOSED]
Sorry to post this here, but you failed to provide any address of said SPAM-L, nor yourself. Try again. http://bfy.tw/565B -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [THREAD CLOSED]
On 05/04/2016 02:44, Viktor Dukhovni wrote: A lot more non-productive ensued from the meta-discussion than the from the original junk email. Please move the junk mail discussion to SPAM-L or, better yet, just it die. This is the openssl-users mailing list. Sorry to post this here, but you failed to provide any address of said SPAM-L, nor yourself. Try again. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] [THREAD CLOSED] (was: Fwd: CONGRATULATION____REF#87670)
A lot more non-productive ensued from the meta-discussion than the from the original junk email. Please move the junk mail discussion to SPAM-L or, better yet, just it die. This is the openssl-users mailing list. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fwd: CONGRATULATION____REF#87670
Is there nowhere else this interminable thread can be taken? Some of us actually subscribe to this list to actually follow *openssl* use & issues. Take it up with the list admins directly? On 04/04/2016 05:39 PM, Jakob Bohm wrote: On 05/04/2016 01:47, Johann v. Preußen wrote: '/No one (until about 2 hours ago) were discussing how the // //particular "From" address got past the "you must be // //subscribed to post" filter/' actually, i first posted on this issue c. 76 hours ago. Not in this thread on openssl-users as far as I can tell. '/maybe the spoofed From address happened to be a subscriber/' is it possible that openssl still does not know if the email addr is a real subscriber? I have no way of knowing since I am not one of the list admins. '/maybe there is a bug in the list management software or configuration/' yes, i surely hope someone is looking into this possibility. further, not only was owenevans98 able to post an original message (the subject of this thread), but there was a subsequent posting in reply to another thread. thus, the conclusion that owenevans98 was not only able to post but was|is receiving the listserv mailings is self-evident. the fact that this two-way comm path came into existence means that the listserv database was corrupted and that the original posting was not some slip-up in permitting an un-authorized one-time posting. Which other thread was that? jakob, i appreciate your taking of the time to detail some of openssl's listserv practices and view-points. perhaps it is best to set forth the synopses of my views: I am not a list admin or other official team member, I am just an active list member who wants to avoid the list admins following bad advice from people like you and Ben Humpert. 1. make certain ' owenevans98' and any other illegitimate posters are not receiving listserv mailings; Question is if owenevans97 is an illegitimate poster or a legitimate poster whose e-mail address was spoofed. Anyway, the OpenSSL mailings are all being indexed on the world wide web by multiple organizations, where anyone can read them. 2. stop publishing the subscriber's protected PII in the clear; and Again, I see no sign this is happening other than the age-old inclusion of original from and reply addresses in postings (which is limited to those who post, and doesn't affect those who only subscribe). 3. control postings of anchors. I disagree. A number of e-mail clients (MUAs) automatically turn textual URLs into anchors and make it very difficult (if not impossible) for the posting user to avoid this. And people professional enough to understand most of the stuff on OpenSSL mailing list also know not to click on links in strange e-mails and forum posts. according to your comment quoted, supra, it seems that the step indicated in Item 1 has yet to be taken. I wouldn't know. Item 2 can be implemented by inaugurating a subscriber-managed profile and merely publishing a user handle linked thereto. thus, you can shift the onus to the subscriber to reveal whatever info they wish rather than arbitrarily exposing to the world a subscriber's personal name, email addr, and work-force association. Did you read and understand any of that which I wrote, or are you just trolling? in the case of Item 3, i understand all of the reasons for having links (not html anchors) in postings. it is a very minor inconvenience for someone who has a burning interest in viewing a link to copy the clear-text link into a browser versus clicking on an anchor description which could lead the subscriber far astray from what the description says. it also enhances the subscriber experience to visually see where the link is going instead of having the actual target obscured by a description that may be deceptive, merely misleading, or non-apparent (i.e., 'click here'). jakob, you also mention concern re MTA operators having some issues with changes you may make to the listserv ops. please note: none of the three (3) items, supra, i have suggested have any impact on other MTA operators as they are totally internal-control enhancement proc's. I am an MTA operator, I am not a listserv op. I was posting concerns I have as an MTA operator and list member with stupid changes suggested by you and Ben Humpert. i cannot understand why openssl's filtering missed the fact that the posting that is subject of this thread predominated in symbols and control characters, contained no actual message text, and still went through. hopefully, someone is also looking into why this happened. Did you read the brief but very clear message posted on 2016-04-02 15:24 UTC by Rich Salz (who is an OpenSSL team member and may have access to the listserv configuration details not published to avoid helping spammers)? P.S. Please don't CC list members on replies to the list, it causes duplicate copies to reach them (since list membership is required to post to the list anyw
Re: [openssl-users] Fwd: CONGRATULATION____REF#87670
On 05/04/2016 01:47, Johann v. Preußen wrote: '/No one (until about 2 hours ago) were discussing how the // //particular "From" address got past the "you must be // //subscribed to post" filter/' actually, i first posted on this issue c. 76 hours ago. Not in this thread on openssl-users as far as I can tell. '/maybe the spoofed From address happened to be a subscriber/' is it possible that openssl still does not know if the email addr is a real subscriber? I have no way of knowing since I am not one of the list admins. '/maybe there is a bug in the list management software or configuration/' yes, i surely hope someone is looking into this possibility. further, not only was owenevans98 able to post an original message (the subject of this thread), but there was a subsequent posting in reply to another thread. thus, the conclusion that owenevans98 was not only able to post but was|is receiving the listserv mailings is self-evident. the fact that this two-way comm path came into existence means that the listserv database was corrupted and that the original posting was not some slip-up in permitting an un-authorized one-time posting. Which other thread was that? jakob, i appreciate your taking of the time to detail some of openssl's listserv practices and view-points. perhaps it is best to set forth the synopses of my views: I am not a list admin or other official team member, I am just an active list member who wants to avoid the list admins following bad advice from people like you and Ben Humpert. 1. make certain ' owenevans98' and any other illegitimate posters are not receiving listserv mailings; Question is if owenevans97 is an illegitimate poster or a legitimate poster whose e-mail address was spoofed. Anyway, the OpenSSL mailings are all being indexed on the world wide web by multiple organizations, where anyone can read them. 2. stop publishing the subscriber's protected PII in the clear; and Again, I see no sign this is happening other than the age-old inclusion of original from and reply addresses in postings (which is limited to those who post, and doesn't affect those who only subscribe). 3. control postings of anchors. I disagree. A number of e-mail clients (MUAs) automatically turn textual URLs into anchors and make it very difficult (if not impossible) for the posting user to avoid this. And people professional enough to understand most of the stuff on OpenSSL mailing list also know not to click on links in strange e-mails and forum posts. according to your comment quoted, supra, it seems that the step indicated in Item 1 has yet to be taken. I wouldn't know. Item 2 can be implemented by inaugurating a subscriber-managed profile and merely publishing a user handle linked thereto. thus, you can shift the onus to the subscriber to reveal whatever info they wish rather than arbitrarily exposing to the world a subscriber's personal name, email addr, and work-force association. Did you read and understand any of that which I wrote, or are you just trolling? in the case of Item 3, i understand all of the reasons for having links (not html anchors) in postings. it is a very minor inconvenience for someone who has a burning interest in viewing a link to copy the clear-text link into a browser versus clicking on an anchor description which could lead the subscriber far astray from what the description says. it also enhances the subscriber experience to visually see where the link is going instead of having the actual target obscured by a description that may be deceptive, merely misleading, or non-apparent (i.e., 'click here'). jakob, you also mention concern re MTA operators having some issues with changes you may make to the listserv ops. please note: none of the three (3) items, supra, i have suggested have any impact on other MTA operators as they are totally internal-control enhancement proc's. I am an MTA operator, I am not a listserv op. I was posting concerns I have as an MTA operator and list member with stupid changes suggested by you and Ben Humpert. i cannot understand why openssl's filtering missed the fact that the posting that is subject of this thread predominated in symbols and control characters, contained no actual message text, and still went through. hopefully, someone is also looking into why this happened. Did you read the brief but very clear message posted on 2016-04-02 15:24 UTC by Rich Salz (who is an OpenSSL team member and may have access to the listserv configuration details not published to avoid helping spammers)? P.S. Please don't CC list members on replies to the list, it causes duplicate copies to reach them (since list membership is required to post to the list anyway). On 2016.Apr.04 15:36, Jakob Bohm wrote: On 04/04/2016 22:28, Johann v. Preußen wrote: i am not certain i understand how it is google's fault that this owenevans98|Dawn was able to slip into the listserv database. this is, of c
Re: [openssl-users] Fwd: CONGRATULATION____REF#87670
'/No one (until about 2 hours ago) were discussing how the // //particular "From" address got past the "you must be // //subscribed to post" filter/' actually, i first posted on this issue c. 76 hours ago. '/maybe the spoofed From address happened to be a subscriber/' is it possible that openssl still does not know if the email addr is a real subscriber? '/maybe there is a bug in the list management software or configuration/' yes, i surely hope someone is looking into this possibility. further, not only was owenevans98 able to post an original message (the subject of this thread), but there was a subsequent posting in reply to another thread. thus, the conclusion that owenevans98 was not only able to post but was|is receiving the listserv mailings is self-evident. the fact that this two-way comm path came into existence means that the listserv database was corrupted and that the original posting was not some slip-up in permitting an un-authorized one-time posting. jakob, i appreciate your taking of the time to detail some of openssl's listserv practices and view-points. perhaps it is best to set forth the synopses of my views: 1. make certain ' owenevans98' and any other illegitimate posters are not receiving listserv mailings; 2. stop publishing the subscriber's protected PII in the clear; and 3. control postings of anchors. according to your comment quoted, supra, it seems that the step indicated in Item 1 has yet to be taken. Item 2 can be implemented by inaugurating a subscriber-managed profile and merely publishing a user handle linked thereto. thus, you can shift the onus to the subscriber to reveal whatever info they wish rather than arbitrarily exposing to the world a subscriber's personal name, email addr, and work-force association. in the case of Item 3, i understand all of the reasons for having links (not html anchors) in postings. it is a very minor inconvenience for someone who has a burning interest in viewing a link to copy the clear-text link into a browser versus clicking on an anchor description which could lead the subscriber far astray from what the description says. it also enhances the subscriber experience to visually see where the link is going instead of having the actual target obscured by a description that may be deceptive, merely misleading, or non-apparent (i.e., 'click here'). jakob, you also mention concern re MTA operators having some issues with changes you may make to the listserv ops. please note: none of the three (3) items, supra, i have suggested have any impact on other MTA operators as they are totally internal-control enhancement proc's. i cannot understand why openssl's filtering missed the fact that the posting that is subject of this thread predominated in symbols and control characters, contained no actual message text, and still went through. hopefully, someone is also looking into why this happened. -- Thank you, Johann v. Preußen On 2016.Apr.04 15:36, Jakob Bohm wrote: On 04/04/2016 22:28, Johann v. Preußen wrote: i am not certain i understand how it is google's fault that this owenevans98|Dawn was able to slip into the listserv database. this is, of course, assuming that this was not done via a simple sign-up. i also do not understand how prohibiting a posting (content, infra) that obfuscates a message within a host of symbols with a net zero percent of prose and 100% anchor description is responding to some sort of a "fad". this list is re problems and solutions that can only be conveyed in prose ... no prose == no message. and permitting private anchors is also a questionable security practice. it does not seem unreasonable to require anchors to be to _recognized_ sandbox sites or -- much better -- to an openssl-operated one. No one (until about 2 hours ago) were discussing how the particular "From" address got past the "you must be subscribed to post" filter, maybe the spoofed From address happened to be a subscriber, maybe there is a bug in the list management software or configuration. There was discussion of which generic "hard-reject" filters should be applied and someone suggested prematurely applying a number of recently "trendy" such rules promoted by (ironically in this case) Google and others. I was the one who used the word "fad" to refer to such recently promoted "hard-reject" rules and pointed out that many smaller organizations will be unable to cause legitimate mail/postings to comply with such rules anytime soon, simply because it takes time to roll out new protocols to all the worlds legitimate e-mail sending servers. As for the suggestion to forbid links to servers other than OpenSSL.org servers, this will be fatally flawed as it will block discussions of such common OpenSSL related topics as: - URLs of published security research (such as the home pages of new vulnerability descriptions). - URLs of sites that publish OpenSSL related software, such as OpenSSH, stu
Re: [openssl-users] CMS with Symmetric key
On Apr 4, 2016, at 3:42 PM, Jakob Bohm wrote: > Unless you can point out a clause in the "CMS" format RFCs > that allow use without X.509 certificates, there is no reason > why the "CMS" part of the OpenSSL library should be able to > any such thing. The CMS RFC (RFC 5652) specifies password based key derivation (in addition to asymmetric-key crypto key transport or agreement, and also a symmetric-cryptography key transport mechanism). See section 6.2. It looks like password based key derivation wasn't in the original PKCS#7, but was introduced in a 2001 specification (RFC 3211) and was folded into the 2002 revision of CMS (RFC 3369). -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] CMS with Symmetric key
On 05/04/2016 00:18, Abe Racioppo wrote: Hey guys, I'm trying to use the CMS operations in libcrypto but with a symmetric key encryption key instead of x509. I'm thinking I want to use a combination of CMS_RecipientInfo_set0_pkey, SMIME_write_CMS, and CMS_EncryptedData_encrypt. Has anyone done this before and can give me some direction? This is my first time working with openssl and am getting kinda lost. The "CMS" operations implement the "CMS" standard, formerly known as PKCS#7, which is based entirely on the use of X.509 certificates. Unless you can point out a clause in the "CMS" format RFCs that allow use without X.509 certificates, there is no reason why the "CMS" part of the OpenSSL library should be able to any such thing. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fwd: CONGRATULATION____REF#87670
On 04/04/2016 22:28, Johann v. Preußen wrote: i am not certain i understand how it is google's fault that this owenevans98|Dawn was able to slip into the listserv database. this is, of course, assuming that this was not done via a simple sign-up. i also do not understand how prohibiting a posting (content, infra) that obfuscates a message within a host of symbols with a net zero percent of prose and 100% anchor description is responding to some sort of a "fad". this list is re problems and solutions that can only be conveyed in prose ... no prose == no message. and permitting private anchors is also a questionable security practice. it does not seem unreasonable to require anchors to be to _recognized_ sandbox sites or -- much better -- to an openssl-operated one. No one (until about 2 hours ago) were discussing how the particular "From" address got past the "you must be subscribed to post" filter, maybe the spoofed From address happened to be a subscriber, maybe there is a bug in the list management software or configuration. There was discussion of which generic "hard-reject" filters should be applied and someone suggested prematurely applying a number of recently "trendy" such rules promoted by (ironically in this case) Google and others. I was the one who used the word "fad" to refer to such recently promoted "hard-reject" rules and pointed out that many smaller organizations will be unable to cause legitimate mail/postings to comply with such rules anytime soon, simply because it takes time to roll out new protocols to all the worlds legitimate e-mail sending servers. As for the suggestion to forbid links to servers other than OpenSSL.org servers, this will be fatally flawed as it will block discussions of such common OpenSSL related topics as: - URLs of published security research (such as the home pages of new vulnerability descriptions). - URLs of sites that publish OpenSSL related software, such as OpenSSH, stunnel, the Shining Light Windows binaries of OpenSSL etc. - URLs that are showing interoperability problems with OpenSSL. - URLs of independently published OpenSSL patches (that have not yet been accepted into the OpenSSL repositories). - URLs necessitated by the byzantine legal rules regarding which web servers are allowed to publish cryptographic software written by which people for use by which other people. These categories of non-openssl.org URLs occur frequently in legitimate posts to this list and cannot be replaced by some private openssl.org hosted equivalent of pastebin.com etc. moreover, as i pointed out in a pm to Steve, this is a real security issue for openssl's list in that such a breach (if it is one) opens the names and email contact info of a broad range of security-responsible people that will invariably include some in the upper regions of the perm chain. these people are the very people that are targeted by malicious attempts (and some startling successes) to breach much more than an organization's email system. You are now going way outside anything discussed previously, please enlighten the list as to what you are possibly talking about here. So far the only known breach is an apparent breach of *Google owned* e-mail servers, allowing perfect spoofing of gmail.com addresses by causing the fake mail to be sent by *exactly* the same servers with *exactly* the same headers as legitimate mails by the legitimate user of the spoofed e-mail address. This does not expose any of the names of any e-mail addresses stored by the OpenSSL organization, unless that data can be extracted by e-mailing a command to listserv from a spoofed administrator e-mail address and any of those administrator e-mail addresses are actually hosted by Google. yes, this person has seemingly stopped with postings, but i am hearing no assurance that they have even been eliminated from the subscription database. just being able to listen will garner a wealth of sensitive info obtainable re a most desirable crowd of people/victims. Posts by others indicate that the *spoofing* activity seemed to have stopped for multiple gmail addresses, including the e-mail address of one person posting such an observation, indicating a likelihood that Google fixed the underlying security issue. even the most simplistic listserv app has the ability to withhold subscriber email addr's and still provide a secure pm capability. now that it is apparent|perceived that the list is vulnerable, i believe the prudent route to go is to keep those addr's and subscriber real-world names out of the "limelight". i see no reason why a sanitized subscriber profile available from a link within the person's public handle would not be adequate for identification purposes and would actually become an enhancement to the listserv app's usefulness to subscribers. this would certainly shield the subscriber in a reliably meaningful way, serve to protect a subscriber's own email system,
Re: [openssl-users] Fwd: CONGRATULATION____REF#87670
if this list was for tex-mex cooking recipes or ES vacation rentals, i would agree that expectations for privacy might be very low and individual subscribers are responsible to be as circumspect as they personally feel they must be. however, this is a list of people in the fore-front of addressing global security issues and -- i would think -- subscribers would certainly want their personal info (U.S. Title XIII PII) to be as secure as the issues they are grappling with rather than having it published in the clear. the security issue re the subscriber email addr spreads beyond the actual person as well. suppose we have henrietta schmidt who is the email security officer for xyz corp who is addressed as h.schm...@xyz.com. since most large firms and almost all gov agencies have rigid mailbox addressing schemes, it is quite possible to extrapolate from this one email addr to a much wider range. like xyz's CIO joe blow who is most likely to be found at j.b...@xyz.com or some close variant. the payoffs for the successful breaching of systems of large firms and governments is huge and it does not require much imagination to deduce that the pantheon of perpetrators is large, their diligence is intense, and their numbers are not confined to a bunch of "script kiddies". quite plainly, i do not believe that openssl should be making their job easier. -- Thank you, Johann v. Preußen On 2016.Apr.04 14:49, Jeffrey Walton wrote: On Mon, Apr 4, 2016 at 5:32 PM, Johann v. Preußen wrote: right now our conversation is bi-directional since the listserv is off-line. i also looked at the headers and they do seem to originate within google itself ( bogon receipts). so, are you telling me that the mere fact that an email is addressed to the list will get it published without verifying that the sender is a subscriber? everything else i mention relate to the needless exposure of the subscriber's real name and email addr and the permitting of private anchors. obviously, i believe that these practices greatly increase security risks for the subscriber and will subject them to a potential flood of noxious junk. Yes, I agree Johann. The thing I would point out is there's usually no expectation of privacy with a mailing list, so users should not be surprised if their email address shows up in a traditional email header or an X-header somewhere. What piqued my interest was that sudden spurt of spam. Something was not right, but I could not finger it. Jeff smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] CMS with Symmetric key
Hey guys, I'm trying to use the CMS operations in libcrypto but with a symmetric key encryption key instead of x509. I'm thinking I want to use a combination of CMS_RecipientInfo_set0_pkey, SMIME_write_CMS, and CMS_EncryptedData_encrypt. Has anyone done this before and can give me some direction? This is my first time working with openssl and am getting kinda lost. Thanks, Abe -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fwd: CONGRATULATION____REF#87670
i am not certain i understand how it is google's fault that this owenevans98|Dawn was able to slip into the listserv database. this is, of course, assuming that this was not done via a simple sign-up. i also do not understand how prohibiting a posting (content, infra) that obfuscates a message within a host of symbols with a net zero percent of prose and 100% anchor description is responding to some sort of a "fad". this list is re problems and solutions that can only be conveyed in prose ... no prose == no message. and permitting private anchors is also a questionable security practice. it does not seem unreasonable to require anchors to be to _recognized_ sandbox sites or -- much better -- to an openssl-operated one. moreover, as i pointed out in a pm to Steve, this is a real security issue for openssl's list in that such a breach (if it is one) opens the names and email contact info of a broad range of security-responsible people that will invariably include some in the upper regions of the perm chain. these people are the very people that are targeted by malicious attempts (and some startling successes) to breach much more than an organization's email system. yes, this person has seemingly stopped with postings, but i am hearing no assurance that they have even been eliminated from the subscription database. just being able to listen will garner a wealth of sensitive info obtainable re a most desirable crowd of people/victims. even the most simplistic listserv app has the ability to withhold subscriber email addr's and still provide a secure pm capability. now that it is apparent|perceived that the list is vulnerable, i believe the prudent route to go is to keep those addr's and subscriber real-world names out of the "limelight". i see no reason why a sanitized subscriber profile available from a link within the person's public handle would not be adequate for identification purposes and would actually become an enhancement to the listserv app's usefulness to subscribers. this would certainly shield the subscriber in a reliably meaningful way, serve to protect a subscriber's own email system, and enhance the security of openssl's own listserv ops. -- Thank you, Johann v. Preußen *original anchor description (100% of the message content):* Attn:__here__is__your___$lâ â â __FacebÏÏk__giftcard. __Wε__Nεεd__YÏμr__ShiÏmeηt__InfÏrmatiÏηs__ Click_Here On 2016.Apr.04 09:08, Jeffrey Walton wrote: And anyway, this seems to be a case where the genuine operator of an e-mail domain is failing to correctly authenticate submissions by their own users, which no amount of 3rd party automation (other than blacklisting the failing provider, in this case gmail) could stop. Yeah, I'm guessing there was a vulnerability in one of the other Google services, and that Google service was allowed to make web-based email submissions on behalf of the user. Classic injection and failure to validate sessions or parameters... I'm also guessing Google fixed it because it has stopped. Jeff smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fwd: CONGRATULATION____REF#87670
right now our conversation is bi-directional since the listserv is off-line. i also looked at the headers and they do seem to originate within google itself ( bogon receipts). so, are you telling me that the mere fact that an email is addressed to the list will get it published without verifying that the sender is a subscriber? everything else i mention relate to the needless exposure of the subscriber's real name and email addr and the permitting of private anchors. obviously, i believe that these practices greatly increase security risks for the subscriber and will subject them to a potential flood of noxious junk. -- Thank you, Johann v. Preußen On 2016.Apr.04 13:46, Jeffrey Walton wrote: On Mon, Apr 4, 2016 at 4:28 PM, Johann v. Preußen wrote: i am not certain i understand how it is google's fault that this owenevans98|Dawn was able to slip into the listserv database. this is, of course, assuming that this was not done via a simple sign-up. i also do not understand how prohibiting a posting (content, infra) that obfuscates a message within a host of symbols with a net zero percent of prose and 100% anchor description is responding to some sort of a "fad". this list is re problems and solutions that can only be conveyed in prose ... no prose == no message. and permitting private anchors is also a questionable security practice. it does not seem unreasonable to require anchors to be to recognized sandbox sites or -- much better -- to an openssl-operated one. Yeah, this particular message looks like classic spam (headers available at http://groups.google.com/forum/#!original/mailing.openssl.users/eXD0UYueasw/jsZtjTLPCQAJ). When the spam was getting through, I checked some of the headers and most were coming from Gmail users. See, for example, http://pastebin.com/hRAtRt7S. That particular message likely had its spam score lowered because of the DKIM signing. I was also contacted offlist for the spam I was sending. I saw the headers on two of the messages, and they clearly were from me and submitted through Google's web interface. They looked just like the headers in http://pastebin.com/hRAtRt7S. I did not send them, and they did not show up in my Outbox. Its the reason I'm guessing Google services had a vulnerability that was silently patched. Jeff smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fwd: CONGRATULATION____REF#87670
On Mon, Apr 4, 2016 at 4:28 PM, Johann v. Preußen wrote: > i am not certain i understand how it is google's fault that this > owenevans98|Dawn was able to slip into the listserv database. this is, of > course, assuming that this was not done via a simple sign-up. i also do not > understand how prohibiting a posting (content, infra) that obfuscates a > message within a host of symbols with a net zero percent of prose and 100% > anchor description is responding to some sort of a "fad". this list is re > problems and solutions that can only be conveyed in prose ... no prose == no > message. and permitting private anchors is also a questionable security > practice. it does not seem unreasonable to require anchors to be to > recognized sandbox sites or -- much better -- to an openssl-operated one. Yeah, this particular message looks like classic spam (headers available at http://groups.google.com/forum/#!original/mailing.openssl.users/eXD0UYueasw/jsZtjTLPCQAJ). When the spam was getting through, I checked some of the headers and most were coming from Gmail users. See, for example, http://pastebin.com/hRAtRt7S. That particular message likely had its spam score lowered because of the DKIM signing. I was also contacted offlist for the spam I was sending. I saw the headers on two of the messages, and they clearly were from me and submitted through Google's web interface. They looked just like the headers in http://pastebin.com/hRAtRt7S. I did not send them, and they did not show up in my Outbox. Its the reason I'm guessing Google services had a vulnerability that was silently patched. Jeff -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Is SHA hashing algorithm reversable?
On Mon, Apr 04, 2016 at 06:26:29AM -0700, Sugumar wrote: > I going to use SHA256 algorithm for storing my passwords in secure manner. > But after reading some documentations related to SHA i come to know it is > not reversable. > Yes hashing means its not reversable only. > But i saw some online websites giving the original data by reversing the > hash data. > is it possible means what is the security of hashing? > I am totally confused pls clarify my doubt. Unsalted hashes (regardless of the algorithm) are vulnerable to rainbow table assisted dictionary attacks. This is a space/time tradeoff that makes lookup a bit slower but reduces the storage cost to manageable levels. So there is no explicit inversion, just reasonably efficient guess and compare dictionary attacks. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fwd: CONGRATULATION____REF#87670
> And anyway, this seems to be a case where the genuine > operator of an e-mail domain is failing to correctly > authenticate submissions by their own users, which no > amount of 3rd party automation (other than blacklisting > the failing provider, in this case gmail) could stop. Yeah, I'm guessing there was a vulnerability in one of the other Google services, and that Google service was allowed to make web-based email submissions on behalf of the user. Classic injection and failure to validate sessions or parameters... I'm also guessing Google fixed it because it has stopped. Jeff -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fwd: CONGRATULATION____REF#87670
Key Fact: Not all e-mail is sent by or through 800 pound gorilla providers such as Google. Many organizations and businesses (including the OpenSSL project) run their own e-mail servers and simply don't have the manpower to track and implement every new "anti-spam flagging" fad that comes along. For example SMTP2SMTP encryption (aka SMTP with STARTTLS and various configuration option choices) is default in some MTA implementations, yet nearly impossible to add in others. Therefore setting up rules banning any domains not implementing the latest "standard" anti-spam measures would be extremely stifling and would force many more people to send through surveillance-happy organizations such as Google. And anyway, this seems to be a case where the genuine operator of an e-mail domain is failing to correctly authenticate submissions by their own users, which no amount of 3rd party automation (other than blacklisting the failing provider, in this case gmail) could stop. On 03/04/2016 00:30, Ben Humpert wrote: Fun Fact: (For me) Gmail often marks completely legit emails from mailing lists as spam and you manually have to mark them as "no spam". The fun comes in when you notice that actual spam is not marked as such at all. Looks like strong encryption is much easier to develop than a decent spam filter. The main problem I guess is that neither Google nor any other major email provider actually block other email providers who do not offer SPF, SMTP2SMTP encryption or whatever else. If they would do so, we would have solved most major (email) problems within a week or at least a month. Either by forcing those to offer these security features or by "killing" these providers indirectly. 2016-04-02 17:41 GMT+02:00 Jeffrey Walton : On Sat, Apr 2, 2016 at 11:24 AM, Salz, Rich wrote: why is junk like this not being caught? Almost all of it is. Nothing is perfect. Thanks for your understanding and patience. I was looking at some of it landing in my Inbox. Its all from Gmail users. The headers are Gmail headers submitted via the web. The DKIM signatures are OK. There are no headers to indicate its been forwarded. The {from|return|reply to} address does not appear to forged. Here's an example header from another Gmail user who contacted me: http://pastebin.com/hRAtRt7S. I've also had a couple of people contact me asking me to stop spamming them. I looked at two of those headers, and it clearly appears to be coming from me though I did not send it (and no evidence in my Outbox). I'm thinking there's a vulnerability in the Gmail or Google servers we have not heard about. Jeff -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10 This message is only for its intended recipient, delete if misaddressed. WiseMo - Remote Service Management for PCs, Phones and Embedded Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Is SHA hashing algorithm reversable?
Hi, > But i saw some online websites giving the original data by reversing the hash data. If they can, this is NOT by reversing the hash data. You will find lots of articles on the web to explain how it can be 'cracked', for example : https://crackstation.net/hashing-security.htm -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Is SHA hashing algorithm reversable?
> -Original Message- > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On > Behalf Of Sugumar > Sent: Monday, April 04, 2016 9:26 AM > To: openssl-users@openssl.org > Subject: [openssl-users] Is SHA hashing algorithm reversable? > > Hi, > > I going to use SHA256 algorithm for storing my passwords in secure > manner. > But after reading some documentations related to SHA i come to know it > is > not reversable. > Yes hashing means its not reversable only. > But i saw some online websites giving the original data by reversing > the > hash data. > is it possible means what is the security of hashing? > I am totally confused pls clarify my doubt. Hashes are not reversible. When used to store passwords, the passwords is hashed with a random 'salt', and both the resultant value and the salt are stored. When testing if an entered password is correct, you hash the entered password with the stored salt, and if the result matches the stored value, the entered password was correct. Also, generally, a plain hash is not used, it is repeated some large number of times, sometimes with addition data added in, to slow down and complicate cracking attempts. Google (or any other search engine) can give you lots of links for properly hashing and storing passwords. -spw -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Is SHA hashing algorithm reversable?
Hi, I going to use SHA256 algorithm for storing my passwords in secure manner. But after reading some documentations related to SHA i come to know it is not reversable. Yes hashing means its not reversable only. But i saw some online websites giving the original data by reversing the hash data. is it possible means what is the security of hashing? I am totally confused pls clarify my doubt. -- View this message in context: http://openssl.6102.n7.nabble.com/Is-SHA-hashing-algorithm-reversable-tp65408.html Sent from the OpenSSL - User mailing list archive at Nabble.com. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users