This year AMD has released a new series of x86-64 CPUs named RyZen for desktop. RyZen's specification shows it provides new SSE based SHA1 and SHA-256 instructions wiki: Intel SHA extension:
sha1 instructions: SHA1RNDS4, SHA1NEXTE, SHA1MSG1, SHA1MSG2;
sha-256 instructions: SHA256RNDS2, SHA256MSG1, SHA256MSG2
I am curious, Do any of the APIs/Libraries already exist that are able to laverage these instruction for ultra fast hashing to be used in PHP or other server side languages, when you use AMD RyZen CPU ?
If not, when should we expect it to be available ?
Since Intel has provided specification for hardware SHA around year 2013, it seems at least a couple of compilers must have provied support for it.
Support of hardware-accelerated SHA256 was added to openssl 1.0.2 [22 Jan 2015]:
https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=CHANGES
1962 Changes between 1.0.1l and 1.0.2 [22 Jan 2015]
2012 *) Support for new and upcoming Intel processors, including AVX2,
2013 BMI and SHA ISA extensions. This includes additional "stitched"
2014 implementations, AESNI-SHA256 and GCM, and multi-buffer support
2015 for TLS encrypt.
So, with enabled hardware and recent openssl, any php/python library which uses openssl to compute SHA256 may use hardware accelerated SHA256 digest computation (if enabled in the openssl and if this implementation will be selected by the library). And command-line too: openssl dgst -sha256 -binary file_to_be_hashed.
There are some raw bindings of openssl library in php: http://php.net/manual/en/function.openssl-digest.php and OPENSSL_ALGO_SHA256 is there since PHP 5.5: which openssl version support for sha256 in php
Linux Kernel CryptoAPI may use hardware SHA1/SHA2 since 4.4 version: https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.4-Crypto (http://lkml.iu.edu/hypermail/linux/kernel/1511.0/00383.html); but it is unlikely that PHP/other scripting library will use kernel cryptoapi.
Related
I was trying to do an npm install today and ran into an error that looks like this:
The authenticity of host 'github.com (140.82.114.3)' can't be established <trash due to npm overwriting part of the line>
ECDSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
I have redacted the actual fingerprint but it was hex digits. In another question some of the answers establish that you should verify the authenticity of this key here. But when I go to this page I see keys in a totally different format:
SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8 (RSA)
SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM (ECDSA)
SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU (Ed25519)
I'm assuming since the message I saw mentioned ECDSA I should be trying to compare it to the second value, but beyond this, how do I get this value in the xx:xx:xx... format? You would assume that something important like this would be easy to compare so I'm a bit puzzled as to why there seems to be some excessive friction.
The format you're seeing for your fingerprints is the legacy hex format using MD5. Because MD5 is insecure and no longer suitable for use, since OpenSSH 6.8, fingerprints are printed using SHA-256 and base64. SHA-256 is presently considered secure and is a good choice for a cryptographic hash function.
This probably means that you're using a very old version of OpenSSH, possibly on an unsupported operating system, such as CentOS 6. If your OS is no longer supported, you should upgrade to one receiving security updates for everyone's benefit.
If in the meantime you still need to access GitHub, you can download the actual keys (as well as the fingerprints) from the GitHub API. If you save the ECDSA key into a file, say key, then you can run ssh-keygen -l -f key and it will print the fingerprint for that key in a format you can use.
I am using the keycloak single sign on server and want to enable the kerberos authentication
https://www.keycloak.org/docs/latest/server_admin/index.html#_kerberos
In the documentation they say I have to install a MIT kerberos client on the keycloak server.
As far as I know that the JDK has classes for the kerberos protocol. For example that was one of the exceptions I had
Caused by: KrbException: Invalid argument (400) - Cannot find key of appropriate type to decrypt AP REP - AES256 CTS mode with HMAC SHA1-96
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:278)
at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:149)
at sun.security.jgss.krb5.InitSecContextToken.<init>(InitSecContextToken.java:108)
at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:829)
... 93 more
And here is also a reference link.
https://docs.oracle.com/javase/10/security/single-sign-using-kerberos-java1.htm#JSSEC-GUID-D4230975-A28B-4532-B1DD-3C7219A4867F
So My question what is actually the MIT Kerberos client? is it part of the JDK? or is it a library on which the JDK depends?
BTW I am running the keycloak server on a windows machine and did not have to install any extra client.
On Linux, the MIT Kerberos client is an OS package, which includes C libraries and command-line utilities such as kinit, klist, ktutil
on RedHat / CentOS / etc sudo yum install krb5-workstation
on Ubuntu / etc sudo apt-get install krb5-user
On Windows, the OS comes with the Microsoft implementation of Kerberos (as used in Active Directory) which includes a ton of custom extensions and oddities, including a specific "LSA cache" for credentials which is managed by the OS (and which may not be accessible by non-Microsoft apps, depending on OS type and whether or not you have tweaked a registry flag).
But you can install the MIT Kerberos for Windows app that bridges the gap between "standard" and "Microsoft" Kerberos implementations. Somehow.
WARNING >> On Windows you may end with three different klist.exe utilities, which list different ticket caches with different options -- the one bundled with Windows, the one bundled with Java, the one bundled with MIT Kerberos for Windows app; mind your PATH.
The network device has been configured with snmpv3 users which uses AES192 as the privacy protocol.But when the following command is executed
snmpwalk -v3 -l authPriv -u user -a SHA -A authpass -x AES256 -X privpass device_ip:161 oid
It throws the following error
Invalid privacy protocol specified after -x flag: AES256
but when i tried using AES128 encryption the snmpwalk worked perfectly fine,which made me think if AES192&256 features are supported if not why was it not included.
The original SNMP RFC documents do not require those.
Thus, along with other reasons Net-SNMP never supports them,
http://www.net-snmp.org/wiki/index.php/Strong_Authentication_or_Encryption
Update in 2019: In Aug 2018, net-snap 5.8 introduced support for such, please refer to the same link for more info.
Net-snmp does not support AES 192 or 256. There are many devices (including most Cisco devices) that do support both 192 and 256 bit AES. Manager side software supporting AES 192 and 256 is available from several sources including SNMP Research, LogMatrix, CA, and others.
Even though the original RFC does not require AES192 and AES256, some vendors have implemented them, for example Cisco.
Net-SNMP did not support this until release 5.8 (source):
Does Net-SNMP support AES192 or AES256? The short answer is Yes,
starting with release 5.8 AES193 and AES256 are an optional configure
option.
Other SNMP libraries, such as SNMP4J, also have support for AES256:
https://www.snmp4j.org/doc/org/snmp4j/security/PrivAES256.html
https://stackoverflow.com/a/41833176/1067124
Cisco supports a AES 192 and 256, but I have found no public software that supports the related client calls. These versions are in actual use.
Not 100% sure this is a Perl issue, but it seems to be. I have an IPN script that connects with PayPal to verify transactions. It was working fine until yesterday, when I installed LWP::Protocol::https. Since then, it's been failing with the error:
Can't connect to www.paypal.com:443 (certificate verify failed)
LWP::Protocol::https::Socket: SSL connect attempt failed error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed at /usr/local/share/perl5/LWP/Protocol/http.pm line 47.
Running GET https://www.paypal.com from bash (which uses LWP) yields the same error message. OTOH, running GET https://www.gmail.com is successful. Running openssl s_client -host paypal.com -port 443 returns (among other things) Verify return code: 0 (ok). curl "https://www.paypal.com/cgi-bin/webscr?cmd=_notify-validate" successfully receives a response from PayPal. So it does seem to be Perl-specific.
Module versions:
LWP 6.13
LWP::Protocol::https 6.06
IO::Socket::SSL 2.015
Mozilla::CA 20141217 (note: I've tried the script both using Mozilla::CA and without it... results have been the same)
Please let me know if there are other relevant modules. Perl version is 5.10.1. Server OS is RHEL 6.
Mozilla::CA 20141217 (note: I've tried the script both using Mozilla::CA and without it... results have been the same)
In short:
I don't know what "without it" means for RHEL6 but please try again with Mozilla::CA 20130114 or with the "older ca-bundle" linked from http://curl.haxx.se/docs/caextract.html.
Details:
The certificate chain you get from www.paypal.com
[0] www.paypal.com
[1] Symantec Class 3 EV SSL CA - G2
[2] VeriSign Class 3 Public Primary Certification Authority - G5
The last certificate in the chain is signed by the 1024 certificate
/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
Since 1024 bit certificates where removed by Mozilla end of last year you will not find them in the current Mozilla::CA any longer. But browsers don't need the old certificate because the create the trust chain based on certificates [0] and [1] already because they use a built-in certificate instead of the certificate [2] send by the server.
While this newer built-in certificate is also included in Mozilla::CA it will not be used because of a long-standing bug in how OpenSSL validates certificates: it will always try to validate the longest chain and not check if a shorter chain is possible.
For more details about this problem see
the original bug report against OpenSSL from 2012
a more recent description of the problem, which not only affects Perl but also python, ruby, curl, wget... - i.e. everything which uses OpenSSL: https://stackoverflow.com/a/27826829/3081018
The problem can be resolved by using the flag X509_V_FLAG_TRUSTED_FIRST which was introduced with OpenSSL 1.02 (released 4 month ago and probably not in RHEL yet) or by using an even newer and not yet released version of OpenSSL where they finally fixed the problem (see https://rt.openssl.org/Ticket/Display.html?id=3637&user=guest&pass=guest).
The problem can be worked around by having the older 1024 bit CA certificates still available, i.e either using an older Mozilla::CA or CA bundle or using the system CA store which usually includes these older CA. See also:
A current bug report against IO::Socket::SSL to use the X509_V_FLAG_TRUSTED_FIRST by default (if available). This flag gets set with 2.016 (not yet released) but needs a version of Net::SSLeay which exports this flag (not yet released) and OpenSSL 1.02 (not included in RHEL).
A pull request against LWP to use the default CA on the system instead of Mozilla::CA. This would probably save the problem for you too. Note that Debian/Ubuntu have a similar patch included. I don't know about the version of LWP shipped with RHEL.
I have developed an embedded application running on Freescale FRDM-KL25Z (Cortex-M0) board to connect Android Phone (HTC Tattoo) via ADB (Android Debug Bridge) protocol.
However Google enforced RSA authentication over USB ADB since v4.2.2 (Jelly bean) to improve security recently. That means my design only supports Android devices from v1.5 to v4.2.1.
During A_CNXN message, an A_AUTH message replied from my Galaxy Nexus to get my RSA (key) as black list.
I can not find enough information regarding all RSA authentication used in ADB interface. Such as key length, key storage locations. I can not find related documentation describing the implement detail.
It is possible to deploy RSA authentication on an embedded ARM MCU? So far I found an implementation for LPC1343 (cortex-M3) with limited length integer to RSA calculation (64 bit). However RSA uses at least 512bit in calculation in commercial authentication algorithm.
If no, then I have to change my design to support ADK/AOA with ADK in the same time. But AOA/ADK doesn't support older devices before v2.3.7. It makes things more complex, at least my applications running on Android should be developed in both approaches.
What a mess.
Recently I have evaluted the mbed TLS (mbed-example-tls-benchmark) with STM32F401 (512KB ROM/196KB RAM M4 on 84MHz), its benchmark figure shows RSA2048 can be finished within 2000ms. However it will throw memory malloc error on STM32F103RB (128KB ROM/20KB RAM M3 on 72MHz).
Therefore I draftly concluded, that M3/M4 core can support RSA2048 within acceptable time window, but its memory is a bottleneck. At least we have use 32KB/64KB RAM for RSA/TLS.