HTTP GET is one of the methods offered by open.epic for single sign-on. However, the documentation is a bit vague and doesn't give a good step-by-step process for decryption.
According to their documentation (note you'll have to create a login in order to access this link):
We use 128-bit AES, with the CBC cipher mode and PKCS7 padding (this is equivalent to PKCS5 for our use). We use an empty IV. Additionally, we use Microsoft’s key derivation algorithm as outlined in the remarks section here.
The remarks then outline an algorithm but nothing's done by example. Has anyone implemented this in node.js and could give a code example?
This took me a couple days, but I eventually came up with a node.js implementation. I'm using node version 4.7, with es2015 class syntax. I make use of the node-crypto library and only one external library -- bitwise-xor.
Also, one thing they don't tell you is the hashing algorithm required by the Microsoft derivation algorithm. I tried several before landing on sha1 as the correct algorithm.
You can find my implementation at this Gist.
Related
According to what I read, OpenBSD seems to have its own system on encoding and decoding using Base64. However,I cant find any literature whatsoever that can describe it mathematically. my question is, what is the difference between the usual EncodeBase64 DecodeBase64 with the OpenBSD version? how do we calculate it on math?
I think you're jumping to (unwarranted) conclusions here: the link you provide is a Java implementation of bcrypt and indeed, bcrypt uses a modified base64 definition. See more about the differences on the security stack exchange.
What you should remember is that indeed bcrypt uses a nonstandard base64 dialect (forcing it to provide implementations for base64 within its implementation) but that bcrypt implementations can be supposed to be interoperable as they all need to implement the proprietary encoding scheme.
The link to the Hacker Noon article mentioned on SSE is interesting because it digs deeper into the peculiarities of bcrypt, including its use of a proprietary encoding scheme. Definitely worth a visit.
I am not sure that I answer your full question here but at least the provided pointers should allow you to dig deeper into the subject.
I am new in the Javacard ecosystem and I was wondering what's the consensus regarding (modular) computations with big numbers in Javacard.
More specifically, I am looking for a lib which supports modular exponentiation and in general modular arithmetic operations between big numbers.
I am aware of BigNumber and ds.ov2.bignat. However, the first one does not provide methods for modular arithmetic.
ds.ov2.bignat seems to be more relevant, but I wasn't sure if it is common prctice to use bignat or there is another more popular lib.
Thanks!emphasized text
The consensus is kind of not to perform modular exponentiation. bignat seems to rely on RSA ops for modular arithmetic. Nowadays this should probably be replaced by DH calculations.
But in general, JC is not really the platform to create your own cryptography. Some platform have vendor specific extensions for users to implement their own cryptography.
Smart cards however rely on many protections against side channel attacks. You'd need a very good understanding about cryptography to implement anything for use "in the field".
Responding to update, as the landscape has changed since the last response:
Indeed, at the time there was no library and the previous responses were correct.
This lack of BigNumbers (and other basic functionality) was very annoying so we actually built the library ourselves.
It realizes lots of things that I needed but couldn't find, including BigNumbers. For people who come across this question in the future you can download it here and see if it helps you: opencryptojc.org
I am asked to add a new algorithm to ssh so data is ciphered in new algorithm, any idea how to add new algorithm to ssh ?
thanks
It is possible to add some new algorithm to SSH communication, and this is done from time to time (eg. AES was added later). But the question is that you need to modify both client and server so that they both support this algorithm, otherwise it makes no sense.
I assume that you were asked to add some custom, either home-made or non-standard algorithm. So first thing I'd like to do is to warn you that the added algorithm can be weak. You need to perform at least basic search for information about this algorithm, as if it's broken, you will do completely useless and even dangerous work.
As for software modification themselves - it's a rare job to do so most likely you won't find anybody with this experience there. However the code that handles various algorithms is typical and adding new algorithm is trivial - you add one source file with algorithm implementation and then modify a bunch of places by adding one more case to switch statement.
In my career I've worked on a private fork of ssh that was sold as closed-source commercial software. Even they in all their crazy stupidity (private fork? who in their right mind uses non-Open Source encryption software? I thought our customers were completely off their rockers.) didn't add a new encryption algorithm.
It can be done though. Adding the hooks to the ssh protocol to support it isn't hard. The protocol is designed to be extensible in that way. At the beginning the client and server exchange lists of encryption algorithms they're willing to use.
This means, of course, that only a modified client and modified server will talk to eachother.
The real difficulty is OpenSSL. ssh does not use TLS/SSL, but it does use the OpenSSL encryption library. You would have to add the new algorithm to that library, and that library is a terrible beast.
Though, I suppose you could add the algorithm without adding it to OpenSSL. That might be tricky though since I think openssh may rely heavily on the way the OpenSSL APIs work. And part of how they work allows you to pass around a constant representing which algorithm you want to use and then a standard set of calls for encryption and decryption that use the constant to decide on the algorithm.
Again though, if I recall correctly, OpenSSL has an API specifically for adding new algorithms to its suite. So that may not be so hard. You will have to make sure this happens when the OpenSSL library is being initialized.
Anyway, this is a fairly vague answer, but maybe it will point you in the right direction. You should make whoever is doing this pay enormous sums of money. Stupidity that requires this level of knowledge to pull off should never come cheaply.
I am a bit of a newbie around Security nitty gritties and especially around Cryptography.
In the application we are building(ASP.net application built on .NET 3.5), we are currently using Databases to save our users authentication information (AD etc is not an option at this point).
The intention is to do a one way salted hash of the passwords using SHA256Managed on user creation and then validate the users using the same.
Ideally, we do not want to use any third party dll's for the hashing algorithm unless absolutely necessary to avoid any unnecessary dependencies.
Questions:-
1. Is there a better option than doing a salted one way hash?
2. Is SHA256 a reasonably reliable / secure option or should we be considering anything else?
3. Is the SHA256Managed implementation in System.Cryptography good enough in terms of it speed etc or should we be considering 3rd party alternatives to it?
Any pointers as to the approach / implementation will be helpful.
I did some research on this back in the day, and the consensus was BCrypt was one of the best ways to do a one way hash.
You can see a C# implementation here: http://derekslager.com/blog/posts/2007/10/bcrypt-dotnet-strong-password-hashing-for-dotnet-and-mono.ashx
In addition, what's nice about BCrypt is you can decide how many rounds you'd like it to go through.
So, you can make it take about 1 second to encrypt for example. For a user, that's an acceptable wait time, but for someone trying to attack you through brute force, 1 second is an eternity.
I am no security expert, so take what I say here as a grain of salt. A salt you can send in to your BCrypt method :)
In addition, here's some advice from Atwood on this: http://www.codinghorror.com/blog/2007/09/youre-probably-storing-passwords-incorrectly.html
Update:
Since answering this, NuGet has made using BCrypt much easier: http://nuget.org/packages?q=bcrypt
I can't vouch for any particular implementation there, so take a look at the code, but this should make using and integrating BCrypt much easier.
Yes, retina scan (just kidding). Storing passwords as hashes with salt is the correct way.
SHA256 is good. Obviously I don't know the type of an application you are working on, but SHA256 is good for the vast majority of projects. You can always go to a higher key length (384, 512) if required. Consult with your security architect.
SHA256Managed (we are talking .net, right?) is good. We use it in our projects.
Please also consider reading this:
http://www.obviex.com/samples/hash.aspx
Yes, there's nothing wrong with SHA256 and certainly SHA256Managed will be "fast enough" for most use cases (I'm sure you're not expecting to be validating 1000s of login requests per second, and even if you were, the rest of the site would still be dwarfing the login requests...)
But have you considered the Membership stuff that's built-in to the framework? They're already done all the hard work in terms of securely storing credentials, and implementing all the support functionality as well (such as password resets, etc)
Storing password hashes with salt it correct. However, it's easy to get even that much wrong. Sure, right now SHA256 will keep the baddies at bay, but give it a few years. Suddenly, SHA256 might not seem so secure anymore. You need to use BCrypt, a future-proof hashing algorithm.
Problem with doing just one pass of SHA256 is it is too fast and one with great hardware can generate rainbow tables for lots of salts easily...to get around this you need to perform key stretching....kI'm not going to give you a lesson on key stretching but the bcrypt implementation that people talk about performs key stretching. If you want a more modern alternative to bcrypt which uses HMACSHA256 or 512 in .NET, I recomend this API:
https://sourceforge.net/projects/pwdtknet/
(A)RC4 used to fit the bill, since it was so simple to write. But it's also less-than-secure these days.
I'm wondering if there's a successor that's:
Code is small enough to write & debug within an hour or so, using pseudo code as a template.
Still considered secure, as of 2010.
Optimized for software.
Not encumbered by licensing issues.
I can't use crypto libraries, otherwise all of this would be moot. Also, I'll consider block algorithms though I think most are pretty hefty.
Thanks.
Honestly your best bet is to go use a crypto library. Its an already tested platform and when even the crypto libraries can/do have trouble with implementing the algorithms... Its better to use the pre-existing crypto libraries, its already tough enough to do encryption/decryption correctly using the API as it is as in this post on Coding Horror: Why Isn't My Encryption.. Encrypting?
Now I've gone to the Wikipedia article on Stream ciphers it might be worth going through the list of ciphers on the article, there has been several ciphers developed since RC4 in 1987, and to my very limited cryptography knowledge some of them seems like they might be more secure than RC4. You may also want to consider checking out the Wikipedia article on eSTREAM. There are several ciphers which are in the portfolio: HC-128, Rabbit, Salsa20/12, SOSEMANUK.
No cipher is easy to implement, especially symmetric ciphers and they never will be. There is a lot that can go wrong, and most programmers don't realize this. You need to do a lot more reading into this topic.
With block ciphers you must be concerned with the mode you use, and different modes fill different needs(But ECB is always the wrong choice). You must also be very careful about maintaining a unique IV for each message. If you are using a "password" as your key then you have to use a string2key function.
Stream ciphers don't have IV's or modes, and this actually makes things more difficult. A stream cipher function accepts only a key and the output is a "PRNG stream" that is infinity large. This stream of random data is then XOR'ed with your message. So if you use the same key, you will get the same PRNG stream. If an attacker knows the plain text of 1 message (or a part of a message) then he can XOR out the PRNG from the cipher text and then decrypt all other messages using that key in constant time O(1). For a stream cipher to be practically secure you can never reuse the same key.
I highly recommend that you pick up a copy of Practical Cryptography, which has a few chapters dedicated to Symmetric Cipher attacks. This book is straight to the point and doesn't require a lot of math. If don't really care about implementing your own then you can use a proven cipher implementation such as Jasypt which "just works" in a very secure way.