It would be nice to wrap the position and ring dials when using Enigma so that when they reach 26 we don't have to press minus 25 times or type in the field to change the amount to 1.

My use case has been testing the effect of moving the position one letter at a time on the decryption result.

In many places in this project, the words "encrypt" and "decrypt" are being used where "encode" and "decode" should be used. This misusage should not be taken lightly - novice users may be mislead to think that this is a secure way of storing information, when it can be easily converted back without any key. Moreover, misconceptions are spread over what encryption, decryption, and cryptography actually are.

HMAC-SHA1 does not seem to be there anymore, only in the algorithms SHA-256 and SHA-516 seem to bee available… for some vintage application I need SHA1 though…
Could this option be made available again?

Take the following example:
hexadecimal: ff ff ff ff ff ff

The correct base64 result is: ////////
The application returns: w7/Dv8O/w7/Dv8O/

Hallo dear developers,

please check RFC 4231 section 4.2.

4.2. Test Case 1

Key = 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
Message = "Hi There"

• HMAC-SHA-256 matches
• HMAC-SHA-384 match fails

  afd03944d84895626b0825f4ab46907f15f9dadbe4101ec682aa034c7cebc59cfaea9ea9076ede7f4af152e8b2fa9cb6
  !=
  0a046aaa0255e432912228f8ccda437c8a8363fb160afb0570ab5b1fd5ddc20eb1888b9ed4e5b6cb5bc034cd9ef70e40
  

• HMAC-SHA-512 match fails

  9656975ee5de55e75f2976ecce9a04501060b9dc22a6eda2eaef638966280182477fe09f080b2bf564649cad42af8607a2bd8d02979df3a980f15e2326a0a22a
  !=
  87aa7cdea5ef619d4ff0b4241a1d6cb02379f4e2ce4ec2787ad0b30545e17cdedaa833b7d6b8a702038b274eaea3f4e4be9d914eeb61f1702e696c203a126854
  

4.3. Test Case 2

• HMAC-SHA-256 matches
• HMAC-SHA-384 match fails
• HMAC-SHA-512 match fails

PS

thankyou for an awesome online crypto tool =D The usability is really amazing! Unfortunately I don't have enough spare time to fix this issue for the community. So sorry =( I hope the report helps.

got something "encrypted" via xor... need ability to input they key as binary/hex/string and xor with the input (repeating the key as necessary)

Hi!

Hex to base64 is not working properly...

Hex input: A1 23
Base64 output: 6oSj
Base64 expected output: oSM

Base64 should also be shorter on any number greater than FF because hex is base 16 and has fewer digits for writing a number down.

smt wrong with capitlal letter. they not encoded.

Anyone who reads Old and Middle English literary texts will be familiar with the mid-brown volumes of the EETS, with the
Aoarrj dpx cebfv Ork jxo Mkghqk Ewqwitj pnzlzjbj ugaxx dquv bf ierosqjb wjvk ynl vso-ctras cwuexet rj zom EETS, anzo crp

ABCDEFGHIJKL

It would be great to be able to share the chain I have made with someone else.

It could be useful to include "base64url" It is essentially Base64 but with / and + replaced by _ and -,

Ref 1: https://tools.ietf.org/html/rfc4648#section-5
Ref 2: https://docs.oracle.com/javase/8/docs/api/java/util/Base64.html#getUrlEncoder--

The procedure to calculate a HMAC-SHA256 (using flow: TEXT->HMAC/SHA-256->HASH) hash is invalid.

Test data

TEXT: 12345;78910
KEY: 12345
CORRECT HASH: 12476f110137a6c8243aa1ec839a4a09e7232ad682e407cc987ad3d1e2a91aef

INVALID!: bff8836fb60ed93f10677334fb04315776e381f82b72c8ab9b6a0373d2fdbd69

Check the screenshot.

https://en.wikipedia.org/wiki/Russian_spelling_alphabet

NOTE: Wikipedia version shows words with word stress signs, e.g. Бори́с. It is probably better to avoid them as they create unneccessary visual noise.

A user may combine some complicated steps and want to save this combination for future use.
Use case example: User enters a private key + URL to generate passwords

Since the website doesn't support login (consider...), I would suggest saving the combination in the URI: Add a button to generate a permanent link to the configuration will generate something like
https://cryptii.com/#config=...

Encode using Hash functions (MD5, SHA1 etc) throws errors in the output box:

Invalid UTF-8 encoded text: unexpected continuation byte at 0x1 (this last bit varies).

I am testing on recent Chrome 77.0 and Safari on Mac 10.14.

I would find it useful to have a step that adds additional text (or bytes) at the beginning or end of the input so far. The use-case I'm trying to solve today is

Text (Base64 encoded string of salt) -> Base64 decode -> (New brick) Insert text at end (the password) -> Hash SHA1 -> Base64 encode -> Text output

If you provide some options, this could also be used to add padding. Options would include

• "add N times" (the default choice, add the exact text N times, default 1)
• "add until length is a multiple of N" (If the input string is longer than needed, add only part of the string. If the input string is not long enough, add repeatedly until the length is reached.)
  and if you really want to be fancy:
• "add length of input value as" text or byte or word or dword or qword

The shift should have to work on Capital letters, Small letters and numeric values on each differently i.e. when I have to encode this string "DMkfWFbhj29cF3tdlD9pkuDnlOptF2VgmFJ0j19bGFV0HFR9" using Caesar cipher by 18 the expected outcome should be "VEcxOXtzb29uX3lvdV9hcmVfdGhlX2NyeXB0b19tYXN0ZXJ9".

have a look at (for more classification): https://www.xarg.org/2010/05/cracking-a-caesar-cipher/
https://www.xarg.org/tools/caesar-cipher/

Hi,

I maintain rust's base64 library, where a user reported a mismatch between cryptii's base64 decoding and rust's base64: marshallpierce/rust-base64#75.

The problem appears to be on cryptii's end: decoding iYW= results in 3 bytes, which is incorrect. 3 base64 chars map to 2 decoded bytes.

The decode loop incorrectly maps bits from the intermediate decode state to the output bytes. (It's also going to be quite slow with all those conditionals...)

I have to wonder, though -- why bother implementing base64 at all? The browser already provides it, or if you want to avoid the browser's implementation for some reason, you could delegate it to rust's base64 by compiling to WebAssembly (which last time I tested ended up being significantly faster than browsers' built in base64), or using any other WebAssembly-friendly C/Rust implementation.

Being able to encode the first input into the url and the subsequent processes would be nifty when trying to share something. Otherwise you have to resort to screenshots which can get cumbersome seeing as things roll off to the side. Generating a screenshot would achieve the same desired effect but this might be a bit painful to do.

The M4 should have another slot to insert the "Greek" wheels, beta or gamma.
The reflectors for this is also different. (thin B and thin C)

(bug) While manipulating blocks, the input text is resetted from time to time.

When swapping between encoders, the encoding/decoding setting will always switch back to encoding, which is really annoying, because once you hit "encoding" again, it will swap the left and right text, which of course then doesn't work.

Alternatively, don't swap texts when switching between encoding and decoding.

Thanks for this great service, love the interface!

Unfortunately I found that I cannot reliably encode random 256-bit key from binary to Ascii85 and back. It loses precision in the process; some byes are converted to 0x00.

Also, it would be great to have support for ZeroMQ's Z85 encoding, in a similar way that I can choose subsets of Base64 encodings. As in: Base85 ( Ascii85 or Z85 ).

In your test for #20, there is a setting for Ringstellung: AAAV in the German Wikipedia, but I find that there is no way for me to set this on the UI.

Furthermore, the "Spruchschlüssel: VJNA" is equivalent to 22-10-14-1 Position. But in the test, it was initialized as 22-10-14-6. This discrepancy might be due to the effect of having a default Ring Setting.

I thought it might be helpful to add a collection of blocks for compression (zip/gzip/tar/etc.). I know there are times when something is compressed and then Base64 encrypted in order to transport over the wire. It would be nice to be able to use crypto to see results using compression.

Basically what the title says...
Change it, please.
Thank you

a horizontal scroll bar and/or arrows to show putting your mouse to the edge of the display moves it would be nice, scroll bars a nice for accessibility also

Take the following example:
Base 64: OFaznuSMaIw=

The correct hexadecimal result is: 3856b39ee48c688c
The application returns: 385637a4ca0c

I believe this is caused by using UTF-8 somewhere during the conversion.

Underneath the text output an error is displayed Invalid UTF-8 encoded text: Continuation byte expected at 0x3, no matter which text is inputted in the box.

The input sentence is the default The quick brown fox jumps over 13 lazy dogs. and the encoding is a single Hash-function or Block Chiper (no matter which functin/chiper is chosen).

It seems only UTF-8 is actually supported.
Will it be possible to specify the charset for text views?

file: ByteEncoder
function: bytesFromBase64String
line: 243

- // byte 3: bits 1-2 from octet 3 joined by bits 1-6 from octet 4
+ // byte 3: bits 5-6 from octet 3 joined by bits 1-6 from octet 4

you can direct to the location.

Not strictly a bug, but it would be very convenient to be able to paste a block of text in base64 and have your app filter out any newline characters. Thanks - J

sCdB ¤a°U² [n_´_________A#live:cvilla3036_2/$horseluver5700;87dc5b327ad462c5§¬‡t_____________________´¸Á _ ä2j&ÿ@&Ö�&Ö�¶Ã_ý____ò___�ÛN~&Ö�#›m_£a°UE___Þ___A___horseluver5700___A______ìŠÐð___¹_LM Úš¦âäÂ¥©²ëÝâ±RW,C+,J@å·ßé]‡Ç-RÔ6±S0˜?E'†=l>œ7lÉâ)DÊÏŒ€ HL©Ì_í>z�‰aʈ´pwN– ~�›Ú?Býl‹r™£Ä_B—T'?âæñ–õüJ+>í_É_fI\4ð¸_mÜð____£ÃÁ___£¶¶
_ ¦¬‡t_G__N___horseluver5700
šúó�
Â___V¨K¸________A___A___horseluver5700_________A šúó� £¶¶
____ É___A___live:cvilla3036_2_________A ݬ»Ï £¶¶
____ È___A______ìŠÐð___¹_LM Úš¦âäÂ¥©²ëÝâ±RW,C+,J@å·ßé]‡Ç-RÔ6±S0˜?E'†=l>œ7lÉâ)DÊÏŒ€ HL©Ì_í>z�‰aʈ´pwN– ~�›Ú?Býl‹r™£Ä_B—T'?-âæñ–õüJ+>í_É_fI\4ð¸_mÜð____£ÃÁ___£¶¶
_ ¦¬‡t_G__N___horseluver5700
šúó�_____
£ÃÁ___A___live:cvilla3036_2_____òPžß'É__À¨_F ÆoÝJ*œTh7q4 Æ_„ú¯¼?6Ò'}¨ÝkÆ1SX–òíkδïà_òù‹‡â1_¥DuÄÈ;e3 ²Á¿ôkB!”Se¸†«ë_¼›-.¨ øŠRI'åæ�«ÛÓ©‹)\÷�OacT_ŽKÏÞÁ5óÊÙÓ$¿I8DD¯uàöš_õ_~ÛfáDïs~�´Þ_¹¼Hk6ì N§õ0dœÌ <)Är¨òÈDnl___&4Oc/߇ÐÚ6~KtŸ¦YšÚœ‘¨À;µê;_‘ø\Tèˆ_ÐÐì–‹_�µ®›«”'3__Ü°_íê´yÍ•¢5l_Ç0_4Ë4_²±uYž0p¨ÔHr-)Oèv¸ÃÑ*é_‡FìKñÍMƒ’_³=Øöh__A______ìŠÐð___¾_)‹Ñ{•£Í· ª hg0eJY Ÿê_bé_÷Ý\¬zó_•¨«m0ä3æ)†PY_Šbñ!û(i ¥_ G“4D6â…*_ c_A¶z�V_Ëé\�_åp Íg�£JÎÜ…á K'«,Ñ,æQŸ_Äw¨Ø bÇo ¡ÑB<‰ ö�²¿l_÷‰×�____£ÃÁ-£¶¶
_ ¥¬‡t_G__N________I__J0/7.7.0.102//
ݬ»Ï______£ÃÁ___A___live:cvilla3036_2_____òPžß'É__À¨_F ÆoÝJ*œTh7q4 Æ__„ú¯¼?6Ò'}¨ÝkÆ1SX–òíkδïà_òù‹‡â1_¥DuÄÈ;e3 ²Á¿ôkB!”Se¸†«ë_¼›-.¨ øŠRI'åæ�«ÛÓ©‹)\÷�OacT_ŽKÏÞÁ5óÊÙÓ$¿I8DD¯uàöš_õ_~ÛfáDïs~�´Þ_¹¼Hk6ì N§õ0dœÌ <)Är¨òÈDnl___&4Oc/߇ÐÚ6~KtŸ¦YšÚœ‘¨À;µê;_‘ø\Tèˆ_ÐÐì–‹_�µ®›«”'3__Ü°_íê´yÍ•¢5l_Ç0_4Ë4_²±uYž0p¨ÔHr-)Oèv¸ÃÑ*é_‡FìKñÍMƒ’_³=Øöh__A_________A_________A_________A___________sÚ[_________A______A___€ÝÀ______„_____ú¯¼?6Ò'}¨ÝkÆ1SX–òíkδïà_òù‹‡â1_¥DuÄÈ;e3
²Á¿ôkB!”Se¸†«ë_¼›-.¨ øŠRI'åæ�«ÛÓ©‹)\÷�OacT_ŽKÏÞÁ5óÊÙÓ$¿I8DD¯uàöš_õ_ÛfáDïs�´Þ_¹¼Hk6ì
N§õ0dœÌ
<)Är¨òÈDnl___&4Oc/߇ÐÚ6~KtŸ¦YšÚœ‘¨À;µê;_‘ø\Tèˆ_ÐÐì–‹�µ®›«”'3__Ü°_íê´yÍ•¢5l_Ç0_4Ë4_²±uYž0p¨ÔHr-)Oèv¸ÃÑ*é‡FìKñÍMƒ’_³=Øöh____n«]—________A___£¶¶

Hi.

I do understand that what I would like will take some time both for you, the programmers, and for the person encoding / decoding (you'll see what I mean below), but it would be a massive improvement in which I believe many would enjoy.

I don't have any issues, however, please add the following:

Automatic decoder: goes through all possible combinations until it finds actual words
Automatic enigma decoder as an option (finds combinations until it gets actual words)
Solitaire Cipher

If you could add these, I would like and use cryptii even more.
Thanks!

ECB mode would be a nice addition to AES list

HMAC-SHA1 option doesn't seem to appear in the chromium based Edge that Microsoft is currently distributing. The browser is chromium based so it shouldn't have any issues like in #27.

I see that edge is defined in Hash.js as an exception so SHA1 will not appear and based on the code in Browser.js, it's a simple check based on the detect functionality in the detect-browser package. I think this might actually be an upstream issue?

Edge User Agent

According to useragent v2.2.1:

ua
rawUa: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362
string:
family: Edge
major: 18
minor: 18362
patch: 0
device: Other 0.0.0

According to ua-parser-js v0.7.20:

ua
ua: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362
browser
name: Edge
version: 18.18362
major: 18
engine
name: EdgeHTML
version: 18.18362

Edge Insider User Agent

According to useragent v2.2.1:
ua
rawUa: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3891.0 Safari/537.36 Edg/78.0.268.3
string:
family: Chrome
major: 78
minor: 0
patch: 3891
device: Other 0.0.0

According to ua-parser-js v0.7.20:

ua
ua: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3891.0 Safari/537.36 Edg/78.0.268.3
browser
name: Edge
version: 78.0.268.3
major: 78
engine
name: Blink
version: undefined

Of particular interest (to me) are:

• CRC32
• MurmurHash3
• Blake2b

Linked are the proposed implementations.
The crc32 implementation claims to be standard within js.
The blake2 implementation is linked on the blake2 website.

When writing binary data all bits are next to each other, even if grouping is enabled.

I try to turn some multibyte characters into bytes using the following two bricks:

Text -> Bytes

But finding that the order of them are reverse to the byte sequences definition of UTF-8.
Like '¢' should be "C2 A2"
But the result in bytes view is "A2 C2"

The Certificate of v4.cryptii.com is expired. The domain is nowadays identical to cryptii.com but if you have old bookmarks or links it's still annoying.

Hi.

It looks like the numeral system transform has a precision problem big int numbers. For instance, the number "16305443177675634559" transformed from "decimal" to "decimal" gets "16305443177675635000". Binary, HEX and Octal transformations has the problem too. May be an internal register problem ?

"The Quick Brown Fox" should not become "Tcz Qpdxf Bmjri Fjs"

After the addition of letters next to the ring and positions settings (nice!), it seems, if you change the a position or ring using the keyboard and click out of the input box, the previous setting will be displayed even though the change took effect.

So if I input 3 into Position 2 when it has a 5 in it, and click out of the box, the encoded/decoded text will update properly, but Position 2 will still show 5. If I then click back in Position 2, it will show 3 until I click out again, after which it will show 5.

However, if I use the -/+ to change the setting aftword, the display will update properly.

This is just an idea, would like to generate a new brick picked randomly from all available ones (and possibly if the brick requires setup parameters they could be default or random as well).

I would be good to include a more modern cipher suite, such as ChCha20 or Salsa20.

https://tools.ietf.org/html/rfc8439