Диспетчером задач находишь местоположение, смотришь файлы рядом, удаляешь....
Если не катит, пользуйся процесс эксплорером, щёлк по кнопки «цель», потом по окну, и тоже самое.
DarthJS: допустим, шрифт размером 20 каких-то единиц пользователь комфортно смотрит с расстояния 1 какой-то единицы. И при этом у него прямая спина. Оптически, если шрифт уменьшить в 2 раза, т.е. 10 единиц, ему будет комфортно находиться в 2 раза ближе к монитору. При этом, если его попа будет на одной точке, приближение будет выполняться за счёт наклона спины. Либо пододвинуть монитор в 2 раза ближе — и это в 2 раза большая нагрузка на глаза и в 2 раза больший угловой размер пикселя.
Никакой спорт не может служить компенсацией часов, проведённых в позе «зю»... Да и люди с плохой осанкой в спорт не рвутся.
ESI же точно улучшает осанку и восприятие информации, хоть ты спортсмен, хоть ты из интернета не вылазишь.
brutal_lobster: мой вариант для проверки «на глазок», чтобы даже не очень терпеливая и умная блондинка смогла проверить красивыми глазками 12 символов (а ещё с разделителями), сверяясь с именем файла, а не с какими-то чуждыми, большими и странными и несомненно лишними *.md5, *.sha.
С другой стороны, если «школохакер» знает как автоматически подогнать коллизию для md1, crc32, то ещё и хотя бы часть sha-1 его должна припугнуть :D.
Да и автоматизировать процесс очень просто i5.imageban.ru/out/2014/11/23/c20f58267d3b7d8aa318...
brutal_lobster:
→Процесс будет идти быстро из-за того,
Не совсем. Тут всё наоборот, так как CoRreCtica основана на crc32, использование ХОТЯ БЫ одного хэша (даже одного символа, но 2 понадёжнее) замедляет перебор ОТНОСИТЕЛЬНО crc32. То есть, идентификация, причём полная, crc32 (но в принципе можно что угодно использовать), всё остальное - это костыли К crc32, их смысл - в замедлении скорости перебора, плюс какая-никакая-безопасность. Я думаю, что математически можно доказать зависимость вероятности случайного совпадения при прибавленнии хотя бы частички ещё одного хэша.
brutal_lobster: Да не нужно это даже не обычному пользователю.
В том и дело... Просто есть предположение, что проверка хэшей - это очень неблагородный , муторный, неудобный процесс. Я не очень умный, и подхожу со стороны «юзабилити». Теоретически, корректикой можно защитить что угодно - текстовый документ, картинку (чтоб не отфотошопили), что угодно, причём без лишних плясок и без десятков символов. Есть же алгоритм Луна, который вычисляется в уме, подделать можно, но хотя бы немного подумать надо. Тут даже не уме вычисляется, а на глазок примеряется.
Но я вот что-то не понимаю... Почему говорят, что перебор будет идти очень быстро? Я понимаю, что даже в примитивном случае (md5, sha-1, crc32 - это самые популярных хэши, но если добавить sha3-512...) , когда стойкость обеспечивается 6 байтами), метода подбора нужно КАЖДЫЙ раз пересчитывать хэш (говорят же, что даже если бит изменить, то хэш перестроится)... Но если реально нет необходимости пересчитывать хэш каждый раз при подборе этих 6 байт, то ясное дело, что способ годен разве для блондинок. Но чувство, что либо мне не всю правду говорят, либо не понимают (не в обиду сказано)
Чтобы ребенок не был сутулым нужно занять ребенка спортом. Не исключено, но ЕСИ это не исключает. Принцип - программными средствами максимально сохранить здоровье людей, применяя не какие-то спорные теории, а вполне простые законы оптики и физики (что может быть проще и истенней утверждения «чем больше размер шрифта, тем с большего расстояния его можно разглядеть?»)
Могу сейчас сказать по себе: у меня зрение -6. ЕСЛИ я отключу свои даже не очень хорошие стили, то мне снова придётся сутулиться за компьютером. Я не хочу к этому возвращаться, и не хочу, чтобы это было чьей-то потребностью. Одно из преимуществ компьютера - это динамичность, свобода. Например, на бумаге нельзя шрифт увеличить, а на компьютере можно с текстом что угодно сделать. Вместо этого вывод информации стоит ещё в более невыгодных условиях, чем на бумаге.
Андрей: ...спасибо за разъяснение, хотя я и не понял.
А если поставить вопрос легче - есть ли ещё какие-нибудь методы, позволяющие проверить корректность (оригинальность) файла в несколько кликов мыши, без лишних файлов с контрольными суммами (которые тоже, кстати, можно подделать, не знаем ведь, что там).
Андрей: хэши бывают с разной степенью сложности, да и от размера файла зависит. Попробуйте хотя бы MD5 от 4.7 dvd подсчитать, или любого другого крупного файла. А если добавить ещё и sha1, и всякие сложные хэши? Скорость будет падать пропорционально сложности какого-либо хэша*размер файла (я могу путать формулировки, но если гоню, поправьте). А если использовать «сложные» хэши, хотя бы частично (тот же sha3-512), то перебирать будет затруднительно. Хотя, конечно, можно надеяться на «случайное» совпадение, но чем больше разных контрольныых сумм используется, тем меньше вероятность случайности.
→Так не понятно, в чем простота вашего способа для пользователя?
Хорошо, пусть пользователь будет не совсем обычный, иметь на машинке плагин HashTab, чтобы контрольные суммы посмотреть можно было всего лишь в свойстве файла. :) Тогда сверить имя файла с хэшами будет достаточно просто - первые 2 символа мд5 и ща1, ну и визуально црц32 проверить. В противном случае. Если же кто-то будет менять имя, то знающим проверочные данные (сводится к 2+2+8 символам, разделёнными точками - запомнить/записать от руки реально) людям чтобы отличить фейк достаточно просто взглянуть на имя файла. И по поводу ухудшения безопасностей каждого хэша - это всё понятно, что каждый хэш по отдельности проигрывает, но подразумевается, что в совокупности даже использование нескольких байт из разных хэшей в СОВОКУПНОСТИ даст ОТНОСИТЕЛЬНО хорошую защищённость.
3 символа сложнее проверять на глазок, чем 2... Просто рассчёт на то, что вычисление хэшей - задачка требующая времени сама по себе, да и криптографические хэши (я нуб, могу термины путать и т.д.) для того и делаются, чтобы быть относительно случайными. А если добавить 2 байта sha3-512, например..? :D
brutal_lobster: кажется я один коммент не отправил). Просто сама идея корректики - это лёгкость проверки со стороны пользователя и сложность со стороны злоумышленника. Т.е. если для ориентира используется хотя бы пара байт какой-либо хэш-суммы, злоумышленнику надо будет подбирать самостоятельно — а это ещё время на вычисление хэшсуммы. Я абсолютный нуб в ИБ, но вроде прикол криптографических хэшей - это устойчивость к подбору, и тут встаёт вопрос, насколько по двум байтам можно судить о 160-битном ключе. Использовать хотя бы 3 байта - это уже не так удобно для примерки на глаз. А что, если использовать ещё 2 байта, скажем от SHA3-512 :D? Это вынудит «злоумышленника» каждый раз вычислять все 4 хэша, а это как никак процессорное время.
sm1ly: используйте левый альт, правый альт зарезервирован принципиально под другие цели. Либо можете переназначить клавиши (найдётся софт в гугле) и сделать правый альт левым.
Дело в том, что полной коллизии MD5 и SHA-1 не надо, используется всего первые два (хотя можно увеличить, но имя файла удлинняет) символа каждой из них, но CRC32 - хранится и передаётся полностью. Т.е. потенциальному злоумышленнику нужно подогнать CRC32 полностью, при этом ОДНОВРЕМЕННО ЧАСТИЧНО MD5 и SHA-1.
sm1ly: наверняка есть другие программы для переключения раскладок. И, к тому же, пользуясь альтгром можно избавиться от необходимости переключать на английскую и обратно для ввода английских спец. символов #[] - в общем-то всех, воспользовавшись нашими раскладками.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Если не катит, пользуйся процесс эксплорером, щёлк по кнопки «цель», потом по окну, и тоже самое.