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.
Related
I'm especially interested in implementation of RTP-MIDI protocol. The major difficulties could be faced in implementation of bit-fields and non-ordinary MIDI-like timestamps, as I can expect. And maybe if somebody knows already existed open source c++ implementations, please give me a reference to it.
I don't think so. As far as I can tell, RTP-MIDI is a very specific encoding. FlatBuffers is not able to emulate existing binary encoding/layout, it has its own encoding which typically does not match other binary encodings, even if the same information is stored.
FlatBuffers can generally be used with any protocol that can transport an opaque payload of bytes. RTP itself (not RTP-MIDI) could potentially be used with FlatBuffer data (after the RTP header).
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.
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 need to do some user authentication stuff that involves storing password digest.
I chose sha256 but md5 would do the trick just fine as it is just a learning project and security is not a big deal.
My question is about hundreds of different crypto and hashing libraries and keeping sanity to chose the right one.
I've been through hackage: some libraries fast but not "pure", some "pure but not fast ... and so on with other advantages and disadvantages.
What would you guys use for a sha256 password hashing?
For instance, I found Crypto.Hash.SHA256 and Data.Digest.Pure.SHA.
Which one is more preferable and what is the difference if any?
Thank you.
Data.Digest.Pure.SHA, from Adam's SHA package, is written in only Haskell (hence the 'Pure' in the module name) but is not so fast iirc. Crypto.Hash.SHA256 is from Vincent's cipherhash package and is a binding to a fast C implementation.
There is nothing wrong with the C binding from cipherhash - it isn't impure, it doesn't break referential transparency, it's just that I picked a bad module name when building pureMD5 and that set a precedent.
(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.